Release and Deployment Management

Release records can be created in multiple ways. Customer can create or link new release manually or from a change or project.

Releases can be classified based on the scope and the risk of the release. Release portfolio/services can be added/edited by customer

Different release types within each classification of release can be defined.

Client admins can create and apply templates for all classifications and types of releases that are needed for their organization. The platform allow that new form and fields can be created by administrator using lowcode capabilities

Client admins can create and apply specific models for all classifications and types of releases that are needed for their organization. Customer can modify or create new workflows or fields/forms and link with workflows / release categories. For perform the action just need go to Workflow Management and create a new release workflow and on Release Portfolio define what will be the new form that those release category will be use.



Release models can be linked to or associated with specific services, software, applications, and/or service components.

Clients can define release packages that can include multiple releases of different release types, as desired by the client. Use release portfolio and Categories that customer can create/apply different models, forms and workflows for attend company needs.

Release schedules can be defined and published with integrated Calendars.

Definitive sources of software can be identified, and the use of definitive software for the release can be validated using Definitive Media process.

Approval tasks can be used to authorize releases before release activities commence and to prevent activities from proceeding if not authorized.

Manual and automated deployment of components in various environments are supported. The platform is able to identify, document, and validate acceptance criteria (from service assurance) to move from one environment to the next and prohibits further deployment based on the status of, and results of, the acceptance criteria, and new acceptance criteria can be created by customer.

The platform supports manual and automated testing and validation (service assurance) of release components and the recording of validated test results using workflow and API integration.

Via relationship between process, the platform has the ability to look up and apply a service or component record, or an IT asset from the respective repositories and to select and apply the service/component/IT asset to the release.

Before the final deployment (into the production environment), a baseline of current production component records can be established to support the need to back out/roll back the release. Customer can create a base line on CMDB and compare versions after deployment finish.

All necessary collateral elements required to support the release can be identified and documented within the release record. The platform support collateral elements required. If a new requirement need to be created the customer can design via low code platform system.

Release acceptance criteria can be identified and documented using approval process on workflow.

Multiple release phases can be performed within the same release record and new phases can be created by customer. The acceptance criteria to exit one release phase can be documented, supporting the decision to proceed with further release phases or to go back in the release for further development and testing.

Hypercare support requirements and procedures can be identified and documented. Customized forms can be created for each type of release. The acceptance criteria (service assurance) to exit hyper care support and to prohibit the full operational support of the release based on the status of hyper care support.



Using approval process on workflow, release authorization/approval based on the completion and validation of acceptance criteria, before subsequent release actions commence, and to prevent activities from proceeding if not authorized.

Release records can be linked or related to existing records or can launch new records from within the release record. The process is linked with all related process (Services. Incident, Request, Change, Problem, Knowledge).

Release success criteria can be identified and documented to determine the relative success of the release, upon the completion of the release using change process and/or documented as Knowledge Asset on Knowledge Base.

Release can be closed manually, or systematically based on the completion of related changes. If customer wants close release, just need to set released status as closed. If want set as automatic can create a automation using workflow that will check all related changes and close release automatically. (Integrations Flow or Rest API).

A post-release review can be launched using Post release Review form on any workflow phase based on the assessed success of the release, and can be performed independent of any potential post-change review for related changes.