====== New Workflow Engine ======

The IdStory IDM includes a proprietary workflow implementation for use in approval processes. The goal is to enable administrators to configure approval processes easily and flexibly, with full control over the sequence and conditions of approval steps. Auditability and robustness of the entire process are ensured.

===== New Workflow Engine Adds Agendas: =====
  * Workflows
  * Approval Processes
  * Tasks (WF)

==== Workflow Agenda ====
The workflow agenda serves to create definitions for individual workflows. A workflow defines a sequence of steps in the approval process using visual programming nodes, where each node represents one step of the approval process by a specific group (or individual) of approvers. The sequence of steps is visually displayed in the workflow definition and edited directly in the IDM editor.

Each node in the approval process has a specific type, and depending on the type, may have additional attributes. The result of each node’s evaluation is an output state (e.g., “approved” or “rejected”), which leads to the next node in the approval process.

<alert type="warning">INSERT SCREENSHOT HERE
</alert>

=== Node Types ===

=== Control Nodes ===
Control nodes are not approval steps themselves but govern the evaluation of the approval process:
  * **Start** - The workflow begins here; no approval step is defined.
  * **End** - The workflow ends here with successful approval; no further approvable step is defined.
  * **Condition** - Defines a condition in the approval process that evaluates to TRUE or FALSE, allowing for branching. It contains attributes:
    * Condition Type
    * Left Operand
    * Right Operand
    * Operator

<alert type="warning">INSERT SCREENSHOT HERE
</alert>

=== Condition Types in the Process ===
  * Role Attribute
  * Guarantor Type Existence - compares the existence (or non-existence) of a role guarantor of the specified type.
  * Role Criticality - compares the criticality value of the role with a numeric value.

=== Approval Nodes ===
Approval nodes define a specific approval step with a set of approvers (could be a single approver). If the WF engine does not find anyone in the set of approvers (e.g., because no one has an assigned role), the approval task is automatically created for the administrator (login: admin).

==== Types of Approval Nodes ====
  * **Approval by Identity** - The node defines a specific identity that approves in the given step.
  * **Approval by Role** - The node defines a specific role representing the approvers in this step, considering role hierarchy (e.g., if the role is assigned as subordinate). Only valid/active users are considered.
  * **Approval by Role Guarantor** - For role change/removal/addition approval, the set of approvers corresponds to the guarantor of the specified role.
    * Includes an attribute to select only a guarantor of a particular type (guarantee-type).
  * **Approval by Script** - The set of approvers is calculated by a Groovy script, which must return a list of identities.
  * **Approval by Supervisor/Guarantor of Identity** - The set of approvers is the supervisor or guarantor of the identity requested for approval.

==== Approval Process Agenda ====
An approval process assigns a workflow to a specific event in IdM that requires approval. The system allows the same workflow to be used repeatedly for multiple events; however, some types of approval nodes (e.g., approval by role guarantor) can only be used with specific approval processes (e.g., those concerning role assignments).

<alert type="warning">INSERT SCREENSHOT HERE
</alert>

==== Approval Processes ====
Each approval process includes:
  * **Name** - A human-readable name identifying the approval process.
  * **Code** - A machine-readable and unique identifier for the approval process.
  * **Event** - The event to which the approval process is applicable. In the current version, IDM supports these events:
    * Role Definition Creation
    * Role Definition Deletion
    * Role Addition to User
      * Triggered on a role change request where a role is added.
      * If marked as “do not approve,” the workflow is not triggered.
    * Role Removal from User
      * Triggered on a role change request where a role is removed.
      * If marked as “do not approve,” the workflow is not triggered.
      * Not triggered for unassignment or departure (automated).
    * Role Modification for User
      * Triggered on a role change request where role attributes or validity change.
      * If marked as “do not approve,” the workflow is not triggered.
  * **Selected Workflow** - Specifies the predefined workflow used for an event that meets the filter condition.
  * **Order** - Approval processes are evaluated based on this order (from lowest to highest), always using the first approval process that matches the event (event and condition).
  * **Condition** - An approval process may contain a condition that restricts the events for which it applies; currently, only a condition on identity type (projection) is supported.

<alert type="warning">INSERT SCREENSHOT HERE
</alert>


==== Approval Process Management ====
Approval processes can be managed by an admin (controlled by IdM permissions) in the approval process agenda where:
  * All active approval processes are visible.
  * Approval processes can be deleted, created, or edited.
  * Current running approval processes always complete based on the workflow that was in place when they were created.

<alert type="warning">INSERT SCREENSHOT HERE
</alert>


==== Concurrency with Old Workflows ====
In the current IdM version, approval processes can be configured using both old workflows and the new system. In such cases, users will see two task agendas (Tasks and Tasks WF), each handling tasks from the respective approval processes.

<alert type="warning">INSERT SCREENSHOT HERE
</alert>

==== Request ~ Task Relationship ====
A role change request can include multiple different changes - removal, addition, modification of individual roles. Each change creates its own instance of an approval workflow = process, according to the applicable approval process rules.

In the approval process, individual users approve or reject tasks. The request is executed = roles are assigned in IdM only after all approval processes are completed (approved or rejected). After the request is executed, provisioning to systems follows, and only approved changes are implemented.