Workflow

The workflow steps define the activities that the survey objects will be processed in. Each step corresponds to an activity that the assignees will be assigned to perform. There may be more than one workflow step for each survey question.

For each workflow step, you define the following:

• Who has been assigned the task.
• Filters for which objects are passed through the step.
• Which mail notification template to use.
• An estimate (a duration of time after which survey reminders can be sent).

Assignee rules

Assignee rules define the user assigned to a task in the launched survey. Generally, it is a virtual (dynamic) reference path to a user object referenced on the data source object.

An example could be a user referenced in the manager property on an identity object that is referenced on a resource assignment. This expression would be written like this: IDENTITYREF/MANAGER. It is also possible to state the name of a user group, for example,User group: Managers.

For each rule, it is possible to specify an exclusion rule. This can be used, for example, to exclude assignees from answering questions where they are referenced in the survey object themselves.

You can specify any number of assignee rules, if the first assignee is not applicable (either because of a filter, exclusion attribute or the reference does not exist for that particular object), the activity is assigned to the next specified assignee.

Workflow step filters

Workflow step filter expressions are used to route survey objects to a workflow step. This is used to skip a workflow step when certain conditions are met. For example, skipping the second review of a resource assignment if it was rejected in the first step.

Estimates

You can configure Omada Identity to send reminders to assignees that have open work items for a survey after a specified time has elapsed. This is enabled by setting a time estimate on the workflow step in the survey template configuration.

See the Survey task reminder section for more information.

The estimate must be entered in XML duration data type. The XML duration data type is written as PnYnMnDTnHnMnS, where P stands for period and n is the number of years, months and days; T stands for time and n is the number of hours, minutes and seconds. P15D sets the estimate to 15 days. PT40H30M sets the estimate to 40 hours and 30 minutes.

In Omada Identity, duration is not calculated on calendar days, but rather work hours and work week; a work week runs from 9-17 Monday to Friday by default. This means that a week counts as 40 hours. If you wish to send reminders after a certain number of calendar days, you should calculate 8 x nDays and set the xml duration to that number of hours.

Workflow Markup language

The workflow section defines the number and order of steps that the survey objects will be processed in. Each step corresponds to a task that users will be assigned to perform. A workflowStep is represented as an Activity in the Process Template.

In the workflow section, you add a workflowStep for each activity that you want to add to the process template. Specify name, title and description for each workflow step. You also need to specify which grid and form the workflow step will use. On each step in the workflow, a different grid and form can be displayed.

You can define a custom mail template for each workflowStep with an assigneeMailTemplateId attribute.

You need to set the assignee for each activity in an assignee tag. It is possible to implement filters (or rules) for how a workflowStep is assigned with an objectTypeFilter.

Attributes

The table below lists the available attributes for workflowStep:

Attribute	Description
Name	The name of the workflow step
Title	The title that will be displayed.
Description	The description of the workflow step.
Grid	The grid that will be used for this workflow step.
Form	The form that will be used for this workflow step.
AssigneeMailTemplateId	The GUID of the mail template that will be used for mail notifications for this workflow step. If undefined, the default mail template will be used.
Estimate	The time that must elapse before reminders are sent. The estimate must be entered in Xml duration data type. Xml duration data type is written as PnYnMnDTnHnMnS where P stands for period and n is the number of years, months and days; T stands for time and n is the number of hours, minutes and seconds. P15D sets the estimate to 15 days. PT40H30M sets the estimate to 40 hours and 30 minutes. In Omada Identity, duration is not calculated on calendar days, but rather work hours and work week; a work week runs from 9-17 Monday to Friday by default. This means that a week counts as 40 hours. If you wish to send reminders after a certain number of calendar days, you should calculate 8 x nDays and set the xml duration to that number of hours.

The table below lists the available attributes for assignee:

Attribute	Description
Expression	A reference path to the user object that will be assigned the activity.
Exclude	Used to define an exclusion rule.

Example

<workflow>

  <workflowSteps>

    <workflowStep name="step1" title="Resource/System owner attestation" grid="grid1" form="form1" description="Performed by either the resource owner (if one is specified) or by the system owner." assigneeMailTemplateId="ecff946d-6b82-434b-ba2f-e93c127d7f46" estimate="PT40H">

      <assignees>

        <assignee expression="/ROLEREF/OWNERREF" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}" />

        <assignee expression="/ROLEREF/SYSTEMREF/OWNERREF" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}"/>

      </assignees>

    </workflowStep>

    <workflowStep name="step2" title="Manager attestation" grid="grid1" form="form1" estimate="P20D" >

      <assignees>

        <assignee expression="/IDENTITYREF/MANAGER" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}"/>

      </assignees>

      <objectTypeFilters>

        <objectTypeFilter left="SURV_ACTION" operator="neq" right="Remove"/>

      </objectTypeFilters>

    </workflowStep>

  </workflowSteps>

</workflow>

Asignee rules

The assignee rules are written in the assignee tag by adding an expression attribute that refer a user reference property. The example below assigns the workflowStep to the resource owner of the resource in a resource assignment.

  <assignees>

    <assignee expression="/ROLEREF/OWNERREF" />

  </assignees>

You can specify any number of assignees, if the first assignee is not applicable (either because of a filter, exclusion attribute or the reference does not exist for that particular object) the activity is assigned to the next specified assignee.

In some cases, there might not be a resource owner specified for a resource. The next logical respondent to the questions would then be the owner of the system that the resource belongs to. This assignee rule would be written as below:

<assignees>

    <assignee expression="/ROLEREF/OWNERREF" />

    <assignee expression="/ROLEREF/SYSTEMREF/OWNERREF" />

</assignees>

Besides stating a reference path in an assignee expression, it is also possible to state the name of a user group by using the syntax “Group:[user group name]”.

Example

<workflowStep name="step1" title="Evaluate data" grid="grid1" form="form1">

     <assignees>

      <assignee expression="Group:System Administrators" />

    </assignees>

</workflowStep>

Exclude

On an assignee expression it is also possible to state an exclude expression. The format and evaluation of the exclude expression is the same as for the expression itself. The exclude result is, however, deducted from the expression evaluation result before the system determines whether it should move on to evaluate the next assignee expression.

In the example the exclude expression /IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825} serves to prevent that the person, who the resource assignment is for, is assigned to deal with it in the survey.

<workflowStep name="step1" title="Resource/System owner attestation" grid="grid1" form="form1" description="Performed by either the resource owner (if one is specified) or by the system owner.">

    <assignees>

      <assignee expression="/ROLEREF/OWNERREF" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}" />

      <assignee expression="/ROLEREF/SYSTEMREF/OWNERREF" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}"/>

    </assignees>

  </workflowStep>

Step filtering

You can define filters for skipping steps in the workflow by implementing a objectTypeFilter.

In the following example a step filter is used to ensure that a survey object is only processed in step2 of the workflow if the user in step1 has not selected to Remove the object.

<workflowStep name="step2" title="Manager attestation" grid="grid1" form="form1">

    <assignees>

      <assignee expression="/IDENTITYREF/MANAGER" exclude="/IDENTITYREF\IDENTITYREF{Type=85D42C0E-0C9D-4D36-9C23-7C768ED06825}"/>

    </assignees>

    <objectTypeFilters>

      <objectTypeFilter left="SURV_ACTION" operator="neq" right="Remove"/>

    </objectTypeFilters>

  </workflowStep>

It is possible to compose a step filter using any of the properties on the survey object type.

The table below list the available attributes for objectTypeFilter:

Attribute	Description
Left	The system name of the field (property) the filter will apply to.
Operator	The match requirements for the right side.Possible values: Eq – Equal to Neq – Not equal to Lt – Less than Gt – Greater than Gteq – Greater than or equal to Lteq – Less than or equal to Contains – Contains the value
Right	The right side of the filter.

warning

The paths in the Assignee step can include a scope variable in filter expressions. However, multiselects are not currently supported, for example: /OWNERREF/IDENTITYREF{ID=@identity_var}/$EffectiveManager.