WHAT IS WORKFLOW STUDIO?
...
Other workflows are user-centric. They do not occur in response to automated system events, but require human interaction, whether that involves simply clicking a button to initiate a workflow or entering and manipulating data at various points of the workflow's lifecycle. Like automated workflows, user-centric workflows comprise process and data layers, but they contain an additional layer as well as:
- a presentation layer that presents itself to the end-user.
Known as the form or lookup, the presentation layer gives users functional access to a workflow by providing the interface that allows them to work with business objects and data.
| Info |
|---|
In the EmpowerID model, users never directly interact with a workflow; rather, they interact with what is known as a request workflow. A request workflow is one of the resource types registered in the EmpowerID Identity Warehouse that is related to resource acquisition and management. A specific request workflow is an Identity Warehouse resource record corresponding to an EmpowerID workflow that is used to control who may interact with the workflow. |
A typical EmpowerID workflow is comprised of a number of components. Depending on the purpose of the workflow, not all of these need to be present.
FORMS
Forms provide components that allow users to enter information into a workflow, which can then be captured and used throughout the workflow. Form data is incorporated into a workflow in this way through a compilation and publication process by which Workflow Studio creates a special type of activity, known as a "Form activity." Once published, Form activities can be added to workflows, where the drag-and-drop property binding capabilities of Workflow Studio can be used to send form data to and from other workflow objects at runtime.
Form Components
Form components used in Workflow Studio comprise two category types: Primitives and RBAC Components. Primitives allow you to place simple objects such as drop-downs, calendar controls, and fields on a form, while RBAC Components allow you to place the properties of objects bound to EmpowerID-protected resources on a form. Each of these RBAC components can be used to return the properties of these protected resources for use in a workflow. For example, if you want to capture data specific to a workflow initiator with an EmpowerID identity, you can add an RBAC Component for a Person object to a form, incorporating into your form design only those properties (person attributes) relevant to your data needs.
...
For both activity lines, the same Business Rule is applied. It is only the evaluation of the rule's logic that differs. For this example, the logic of the Business Rule could look like the following code:
return CurrentWorkflow.OperationActivity.OperationExecuted...
- The workflow is initiated by a person.
- EmpowerID presents a form or lookup (the Presentation Layer) to that person, which requires the input of data.
- The data entered in the form or lookup is bound to a second activity, which uses the data to perform some type of work.
- The workflow progresses to an Operation Activity, which checks the access of the person initiating the workflow before allowing its code to be executed. If the person initiating the workflow lacks the authority to proceed, EmpowerID routes the operation to any designated approvers, placing a task on their dashboards and sending email notifications as appropriate. At least one approver must approve the request before the workflow can progress.
- At this point, the process flows to one of two activities based on the response of the approver and the logic of the Business Rule applied to the lines connecting the Operation activity to those activities. In our example, the red line depicts where the process flows if the approver denies the request and the green line depicts where the process flows if the approver approves the request.
- If the request is approved, the workflow proceeds to the Wait activity (designated by the diamond shape), which idles the workflow for a predetermined period of time to allow the initiator to perform some tasks. If the request is denied, the workflow proceeds to the Final activity, designated by the oval shape, which then proceeds to exit the workflow.
- Once the idle time passes, the process flows either to the second Operation activity or the Final activity depending on the logic of the Business Rule applied to the two lines connecting the Wait activity to the those activities.
- If the request is approved, the workflow loops back to the Wait activity where the process outlined in step 6 above repeats itself. If the request is denied the workflow proceeds to the Final activity and exits the workflow.
...