Workflows

All users permitted to create a new record for an entity have access to an icon with a plus sign followed by the name of the entity. This icon is located in the upper left side of global views such as the card, table and hierarchical views.

Following the same logic, users can update a record for an entity when they see the Edit icon. When they select this icon, they are redirected to an edit screen.

By default, these actions are free from control and users permitted to see affected records can see these changes. In order to enforce controls, you can activate workflows to involve actors that review, approve and finalize any creation or update operated by some profiles. Use the Metadata Administration perspective to activate workflows.

You can activate workflows for create and update operations. Duplicating a record is considered the same as creation, so if you activate the workflow for create, it will also apply for duplicating.

Activating the workflow on Create causes the creation icon to redirect the user to the first step of the workflow consisting of creating a record in a workspace. This workspace isolates all modifications operated in the workflow until its completion. The completion of the workflow can lead the creations or updates being validated and visible to all, or cause their cancellation. You can define different actors for each operation and entity.

You can define each actor as a collection of user roles. These roles are either static or dynamic. A static role is defined in the directory and directly impacts users. A dynamic role is resolved from the data and is conditional to the subject of the workflow being an occurrence of an entity. A dynamic role can be, for example, the owner of this occurrence which is set on the occurrence itself as a reference to a Group itself referencing a static role. A dynamic role is then a dynamic allocation of a static role contextual to data. See Dynamic roles for more information.

If no role is defined for an actor, or if only dynamic roles are defined but the latter are not mapped to static roles, the act of reviewing, approving or finalizing is then skipped.

The reviewer reviews the creation or update of an occurrence to make sure all required information is present and qualitative enough to be submitted to approvers. If not, he can reject the changes leaving a mandatory comment. The initiator of a workflow will receive a task to either cancel the operation or make the necessary changes according to the reviewer’s comment and ask for a new review. This review, even if offered to many roles, will be operated by only one user; the one who takes the task.

Approvers must approve or reject the operation. Offered to many roles, one user from each role must perform this action. If one of them rejects the operation, the initiator of the workflow will receive a task to either cancel the operation or make the necessary changes according to the approver’s comment and ask for a new review. Once approved by all approvers, the operation can be finalized.

A user can be involved to finalize the operation if extra actions must be performed but are not authorized for previous actors.

Provisioning workflow configuration

The provisioning workflow follows the same pattern except that a third kind of approvers can be configured, the assets owners.

The finality of this workflow being the composition of a view from collected assets, each of these assets having or not a owner defined, these last can be involved to approve the creation of the view and finally the usage of their assets.