Astra Schedule Help (7.5)


Hide Navigation Pane


Previous topic Next topic  


Previous topic Next topic JavaScript is required for the print function  


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:



Event Meetings


Equipment and Services

Event Request Forms



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

Definitions and Concepts


A workflow is a sequence of States and Transitions with associated Actions.

Workflow State

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.

Event (User) Status

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

Notifications and Approvals

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

Notification List

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.

Resource Usage Types

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?