Versioning
Versioning | |
|---|---|
Create new diagrams or object versions. | When new processes or objects are created, new versions are automatically created. Several versions can be created and edited in parallel for processes. |
Delete diagrams and objects that are being edited. | Processes or objects that are in progress can be deleted. |
Create a new version of released processes and objects. | New versions must be created each time to revise released processes or objects. |
Automatic versioning of processes and objects | The version numbers for processes and objects are assigned automatically (integer for 'Released/Valid' (e.g. 1.0), decimal for 'In progress' (e.g. 1.1)). A manual adjustment is not possible. |
Release Workflow | |
Sharing: add more approver/approver groups (optional) | By default, the person responsible and, if applicable, the quality manager are stored as approvers. Additional approver/approver groups can also be configured (optional). For groups, the deposit of the number of permits required is possible. |
Release: Validate methodical rules in the process | Before release, the application of BPMN 2.0 semantics is checked, and modeling errors are pointed out. If essential information is missing, the release workflow cannot be started. |
Release: Send diagrams and objects to the release | After changing the status of a diagram or object, the release workflow starts automatically. The default sequence is Author - (QM) - Person responsible, with optional additional approver group: Author - (QM) - Approver - Responsible. |
Release: Ignore validation rule warnings to start the release (enable/disable) | Before release, the application of BPMN 2.0 semantics is checked, and modeling errors are pointed out. If these are "warnings," the release workflow can still be started. |
Release: Define diagram and object validity start "Valid from | The validity starts with processes and objects that can be freely defined. If no date is defined, the validity start is set to +14 days by default (configurable). There is no automatism when the validity end occurs. |
Release: Enter reason for revision (must have attributes) | Before a process can be sent to the approval workflow, the reason for the revision must be entered in a text field. The input of the reason is optional for objects. |
Release: Automatically forward requests for release to approvers | After a status change, the diagram/object to be checked is forwarded to the first approving instance (e.g., quality manager). In case of approval, the request is forwarded to the second instance for release, in case of rejection the release workflow is interrupted. In all cases, the author is informed. |
Approval: Inform approvers by e-mail about pending requests for approvals (optional) | It is also possible to automatically notify approvers by e-mail when a request for approval is submitted. |
Sharing: Automatically create and view requests (tasks) for approvers | Once the approval workflow is started, a request to the approver is automatically generated and displayed in his workspace. |
Release: Manage requests (tasks) | Outstanding or completed requests are displayed in an overview for further administration. |
Release: Call process/object directly | The process or object to be released can be accessed directly from the request via a link. |
Release: Approve or reject the release of processes and objects | The release of processes or objects can be approved or rejected at the push of a button. A reason must be entered in the text field in case of rejection. |
Set processes and objects to 'Expired. | A process or object can receive an "expired" status. The procedure is similar to the release workflow. Expired processes or objects can be reactivated. |