Workflow |
|
|
|
|
Workflow |
|
|
|
|
The Astra Schedule workflow system is a powerful, flexible, task processing and rules engine. Most of the rules about how an event behaves during its lifecycle are defined in the workflow. The power and flexibility of the system is provided through configurable XML-based workflow definition files. These files include the following information:
•Workflow states and their meaning
•State transitions requirements (entry and exit criteria) and their triggers
•Associated actions
The workflow engine runs as a background service so that user interaction is not necessarily required to move from one state to another. This allows time/date rules to be processed to accommodate escalations and/or reminder type actions. The workflow engine logs the transition history for each event. Log information is currently only available as part of the task agent job list.
As an event or related activity is processed by the workflow system, the following questions are evaluated:
•Which records and fields are involved?
oThe record types include:
•Events
•Event Meetings
•Rooms
•Equipment and Services
•Event Request Forms
•Users/People/Customers
•What will trigger an action?
oThe workflow rules define what will trigger an action by the system (i.e. change of a certain value)
•When should the rule be evaluated?
oInserting a new record
oEditing a record
oOn change of value of a specific field
oBased on date/time
•When should action be taken?
oBased on the value or combination of values of specific fields
oRequest of event
oRequest of room
oRequest of equipment item or service
•What action should be taken?
oActions include:
•Require approval
•Send email
•Call an additional workflow rule (room/resource WF or other event WF) or action
A workflow is a sequence of States and Transitions with associated Actions.
A workflow state is a sequence point in a workflow where the system is waiting for a change or stimulus. More simply put, the workflow state is the current state of the record as defined by the workflow rules. For example, an event may not yet be "scheduled" due to a pending approval, regardless of the user's intent. The workflow rule may require that an approval be obtained before the state can continue to scheduled.
All workflows have an initial, default, state and one or more final states.
The event status represents the user's intent for the record.
A user may intend to try to schedule an activity all the way to completion, but the workflow rules may prevent this and instead force it to be in an intermediate state (i.e. "requested"). The user interacts with a status value, and the system responds by evaluating the workflow rules and attempting to arrive at the user's status. In other words, the user may tell the system "Please try to be scheduled" and the system answers "Due to rule x you must be requested".
The event status is user-defined and may be edited on an event at any time. The event status is interpreted by the workflow engine to make appropriate state transitions.
When the event status is edited, the workflow system will evaluate the states, transitions, and actions for the event, meeting(s), and resource(s).
The status may be edited for a child (meeting or resource) independently, but if the parent is edited again, it will attempt to apply the status change to all components within the event.
Workflows progress from one state to another state by making a transition.
Transitions can be triggered by:
•Event properties (e.g., from the request form)
•Changes to event properties
•Answers to questions asked to users
•Time-based criteria
An action is a side-effect of a workflow transition.
An action can be triggered:
•By taking a certain transition
•When a state is entered
•When a state is exited
Example Actions:
•Ask a multiple-choice question to a group of people
•Send a notification to a group of people
•Change room or resource usage
•Change event properties
•Run a report and send in an email (using specified parameters)
•Send an email message
•Perform a POST to another system
Notification and Approver Groups are created and associated with rooms and resources (as before)
A customized Workflow can also use these groups directly (e.g., chained approvals)
Approvals have been generalized into multiple-choice questions
You can request more information for a question before answering
Notifications are stored in a per-user/per-group list.
Notifications are viewed and either acted upon or dismissed within the application.
Each user can set up a schedule on which to receive notice of changes to their list. For example, a user may be notified of a new item immediately, or maybe only once per day.
If there are no new list changes, then there are no email notifications.
Usage Types map directly to workflow states and apply to rooms and/or resources associated with an event.
The usage type rule is customizable, and determines whether or not the item is reserved and how the reservation is displayed in the system.
Configuration options include:
•Is the item reserved?
•Is the item reservation displayed on the calendar views?
•Is the item reservation displayed on resource selection grids?
•If the item is displayed, what color is the reservation on the display?
•If the item is not reserved, is a user warned when creating a conflicting reservation?
Page url: ?workflow.htm
