Managing tasks

Edit online

The Flow designer section facilitates with a list of tasks that can be used individually or with other tasks to create the appropriate flow.

The tasks along with decision points enable the admin user to construct a defined flow to accomplish a business requirement.

The following tasks are listed in the Flow designer to create the flow:
Approvals
User and identity
Integration tasks
Application and pages
Note: The flow that is authored by using the Initiate access request approval and Complete Approval nodes must not be directly launched in a browser. The approval-based flows must be published and triggered through access request API or USC (Add app flow).re

Approvals

Initiate access request approval
Note: Initiate access request approval task is a requestable feature, CI-49772 (Request access with advance workflow). To request this feature, contact your IBM Sales representative or IBM contact and indicate your interest in enabling this capability. You can also create a support ticket with the feature number if you have the permission.
Purpose - The task can be used to initiate approval for an access request that is made to a specific application.
The following is the parameter of the Initiate access request approval task:
Table 1. Output parameters
Name Description
requestId The requestId is used to track the proceedings of the approval. requestId property can be retrieved in the flow as @context.requestId@.
Ask for approval
Note: Ask for approval task is a requestable feature, CI-49772 (Request access with advance workflow). To request this feature, contact your IBM Sales representative or IBM contact and indicate your interest in enabling this capability. You can also create a support ticket with the feature number if you have the permission.

Purpose - The task can be used to ask for approval from the configured list of approvers for the request populated against requestId. requestId is typically populated by tasks like Initiate access request approval.

The following are the parameters of the Ask for approval task:
Table 2. Input parameter
Name Description
Approver source Select an approver source:
Role-based approvers
You can select multiple roles for Role-based approvers.
  • Application owner
  • User's manager
Users
You can select multiple users in this section.
Groups
You can select single group in this section.
In the Basic view you can select the approver. In the Advanced view, you can enter an expression to specify one or multiple approvers
Timeout (in days) The duration in which the approver(s) can take an action on the request. The duration can be entered as a number or an expression. The same duration is applicable to both approvers and escalation approvers (if any).
Note: The email approver access requested page can be modified to include request approval timeout. Use the @TIMEOUT.VALUE@ macro to render this data at run time. See Modify email approver access requested page for more details.
Escalation approver source (optional) Select an escalation approver source:
Role-based approvers
You can select multiple roles for Role-based approvers.
  • Application owner
  • User's manager
Users
You can select multiple users in this section.
Groups
You can select single group in this section.
In the Basic view you can select the approver. In the Advanced view, you can enter an expression to specify one or multiple approvers
Timeout action Action to be taken if the approver does not act in the configured duration. The action can be selected from dropdown or entered as an expression..
Table 3. Output parameters
Name Description
approvalStatus The action taken by any of the selected approvers on the request.
Note: When the approval times out for both approvers and escalation approvers, timeout error details get saved in error object inside context and the flow continues instead of displaying the error page.
Complete approval
Note: Complete approval task is a requestable feature, CI-49772 (Request access with advance workflow). To request this feature, contact your IBM Sales representative or IBM contact and indicate your interest in enabling this capability. You can also create a support ticket with the feature number if you have the permission.
Purpose - The task can be used to complete approval request populated against requestId. requestId is typically populated by tasks like Initiate access request approval.
The following are the parameters of the Complete approval task:
Table 4. Output parameters
Name Description
completionStatus The response received after the request is completed.

User and identity

Identity proofing
Note: Identitiy proofing task is a requestable feature, VDEV-33143 (Identity Proofing task to the Flow designer). To request this feature, contact your IBM Sales representative or IBM contact and indicate your interest in enabling this capability. You can also create a support ticket with the feature number if you have the permission. IBM® Verify trial subscriptions cannot create support tickets.

Purpose - The Identity proofing task provides a list of configured flows that enable to capture and manage identity proofing data in a secure environment. The user is redirected to an external configured vendor to prove their identity.

The following are the parameters of the Identity proofing task:
Table 5. Input parameters
Name Description
Flow The Flow drop-down field lists all the configured identity proofing flows. See Managing identity proofing for further details on creating a new identity proofing flow.
Action required The purpose of this parameter checkbox is to indicate whether an existing flow can be used to come back and resume its task.
Table 6. Output parameter
Name Example
identityProofingData 
{
   "af0a20e3-d6ac-444f-b1cc-68667f59ed31":{
      "vendorId":"bf0a20e3-d6ac-444f-b1cc-68667f59ed31",
      "decision":"approve",
      "processedAttributeMapping":{
         "1":"Joe",
         "2":"Smith",
         "3":"1234 Yellow Lane"
      }
   }
}
  • af0a20e3-d6ac-444f-b1cc-68667f59ed31 - ID of the identity proofing flow.
  • vendorId - ID of the vendor that did the proofing (for example, ID Data Web).
  • decision - whether the user is proven or not. Values can be approve or deny.
  • processedAttributeMapping - the user attributes that are processed and proven.
idpStatus Variable that holds the decision of approve or deny. It follows what is set in decision in the identityProofingData.
Create user
The following are the parameters of the Create user task:
Table 7. Input parameter
Name Description Example
userFormData User submitted form details. 
{
    "userData": {
        "1": "google-oauth2|1033116550041553242@jke.samlfed.com",
        "3": "jessica@jke.com",
        "6": "Jessica",
        "7": "Hill"
    },
    "userAgreements": [],
    "externalData": {},
    "usernameAttribute": ""
}
Note: The userFormData contains the attribute id for a given attribute. The attribute name for id can be found in the response of GET Attributes API.
Table 8. Output parameters
Name Description Example
User The user created in the system. <Scim object representing user detail>.
Note: When the task execution fails, its details get saved in error object inside context and the flow continues instead of displaying the error page.
Fetch User
The following are the parameters of the Fetch user task:
Table 9. Input parameters
Name Description Example
Username The name of the user that is to be searched. 
google-oauth2|1033116550041553242@jke.samlfed.com
or any property available at flow instance runtime.
Table 10. Output parameters
Name Description Example
User The user details corresponding to the provided username. <Scim object representing user detail>.
Note: When the task execution fails, its details get saved in error object inside context and the flow continues instead of displaying the error page.
User form

Purpose - The User form task provides a list of configured user forms that can be rendered to collect user data and consent.

The following are the parameters of the User form task:
Table 11. Input parameters
Name Description
Form The Form drop-down field lists all the configured user forms.
Action required The purpose of this parameter checkbox is to indicate whether an existing flow can be used to come back and resume its task.
Table 12. Output parameter
Name Description Example
userFormData All the user attributes and consent are stored in JSON format. 
{
    "userData": {
        "1": "google-oauth2|1033116550041553242@jke.samlfed.com",
        "3": "jessica@jke.com",
        "6": "Jessica",
        "7": "Hill"
    },
    "userAgreements": [],
    "externalData": {},
    "usernameAttribute": ""
}
Note: The userFormData contains attribute id for a given attribute. The attribute name for id can be found in the response of GET Attributes API.

Integration tasks

Function
Purpose - The Function task evaluates and fetches result for a single or multi-line expression. This expression can be used to update an instance variable to apply functions and conditions according to the need.
Pre-requisite:
  • The function uses a set of domain objects for evaluation, cloud directory user, identity source credential, and attribute context. In order to use cloud directory user, flow instance runtime is expected to contain user property added using the Fetch user task, idsuser for identity source credential. The existing flow instance properties are part of attribute context.
  • The policy with rules must be configured to check the IP or geographical location.

The flow designer supports requestContext, ctx, idsuser and user objects to author a custom function.

The following are the parameters of the Function task:
Table 13. Input parameters
Name Description Example
Rule Expression Single-line or multi-line expression. 
  jsonToString({
    "ctx": ctx,
    "idsuser": idsuser,
    "user": user,
    "requestContext": requestContext
  })
Table 14. Output parameters
Name Description Example
JSON All properties should be returned in JSON form and can be retrieved as @context.propertyName@. 
{"familyName": "Hill","givenName": "Jessica"}
Note: familyName property can be retrieved in the flow as @context.familyName@
Note: When the task execution fails, its details get saved in error object inside context and the flow continues instead of displaying the error page.

Application and pages

Page
Purpose

- The Page task can be used where a page form is to be rendered to display any UI content in the browser. The task lists all the configured templates in a drop-down selection.

Pre-requisite: The themes must be customized under User experience > Branding section or it gets set to default.

The following are the parameters of the Page task:
Table 15. Input parameters
Name Description
Theme Themes give the users a customized look and feel of pages that are displayed by the Page task. The Theme drop-down field lists all the available themes. The preferred theme can be selected for branding the page.
Template The Template drop-down field lists all the configured templates.
Action required The purpose of this parameter checkbox is to indicate whether an existing flow can be used to come back and resume its task.
Redirect
Purpose - The Redirect task can be used to go to any URL after the implementation of some nodes in the flow.
The following are the parameters of the Redirect task:
Table 16. Input parameters
Name Description Example
URL The URL that must be redirected to. https://api.jke.com/resources/ or any property available at flow instance runtime.
Action required The purpose of this parameter checkbox is to indicate whether an existing flow can be used to come back and resume its task.
Note:
  • User can access flow instance properties as task parameters by constructing an expression. To construct an expression, see Expression support in flow.
  • Refer to Managing flow instance to understand the details that are involved in data exchange between the tasks and decision points after the published flow is triggered using the Execution URL.