Workflows

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

Following the same logic, users are allowed to update a record for an entity have access to a button with a pen and the keyword “Edit”. By clicking on this button, the user is redirected to an edition form.

These actions are by default free from control and their result is then directly visible by all users permitted to see the affected records.

In order to activate controls, workflows can be activated to involve actors to review, approve and finalize any creation or update operated by some profiles. The activation of workflows can be made from the Administration perspective.

Workflows can be activated for the operations of Create and Update. Duplicate record is considered as creation, so if you activate the workflow for Create, it will also apply for duplicate.

Activating the workflow on Create will cause the button of creation to redirect the user to the first step of the workflow consisting of creating a record in a workspace. This workspace is isolating all modifications operated in the workflow until its completion. The completion of the workflow can lead the creations or updates to be validated and visible to all or cause their cancellation. For each operation and for each entity, different actors can be defined.

Each actor can be defined as a collection of user roles. These roles are either static or dynamic. A static role is defined in the directory and directly affected to 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.