Workflows have several dependencies and working parts that need
to be configured in order to function properly. Typically, a
workflow operates in the following fashion:
A workflow instance is started when a client
application triggers an event listener, or a user manually starts a
workflow.
The event listener or the manual entry signals the
initiation of the workflow process.
The workflow's primary action is invoked and the
process begins.
The primary action instance invokes one or more
subsequent actions.
Each action has attributes assigned that govern how
it should operate. The action in turn invokes one or more actions
according to its configuration.
One of the components of a workflow can be requiring
approvals from designated approvers of actions (changes, requests,
and so on). When the workflow encounters an approval action, the
process is temporarily paused, and resumes once the approval has
been received.
The sequential or parallel routing continues until
each thread reaches a termination point.
When you include an action that involves more than one approver,
you can decide whether to require all approvers to OK the request
or whether only one approval is required. If you specify All
must approve, you can also indicate a percentage, in order to
allow something less than 100% (percentages are always rounded up).
If you specify Any may approve, the process will
continue as soon as a single approval has been received.
If you include a group, Process Manager treats the entire group
as an individual approver. Once an approval or denial is recorded
by any member of the group, the approval is treated as a group
decision and other group members can no longer approve or deny.
Required components of workflows
You need to configure the following components to successfully
run a workflow:
Event listeners, as well as associated field mappings
when required.
Processes, meaning the layout or order of
actions.
Actions with the appropriate attributes.
Attributes with the appropriate values; including
participants, authentication information, parameters, and so
on.
Participants, also called contacts, to perform tasks.
Participants fall into two categories:
Animate participants, specifically users and groups,
who perform manual tasks based on permissions, assignments, and
user information. To include users and groups as participants in
workflows, you need to have created connections for them using the
Database Utility. See "Configuring users and
groups".
Inanimate participants, specifically Process Manager
and other applications, perform automatic tasks based on system
configuration.
Optional components of workflows
You can also apply optional components to your workflows:
E-mail templates to customize the formatting and
messaging of e-mails sent to participants of processes. See
"E-mail templates"
Auditing templates to format data provided in the
audit history. See "Auditing templates"