Event Workflow Overview

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 workflow engine runs as a background service so that user interaction is not necessarily required to move from one state to another.  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:

  1. Which records and fields are involved? The record types include:
    • Events
    • Event Meetings
    • Rooms
    • Equipment and Services
    • Event Request Forms
    • Users/People/Customers
  2. What will trigger an action?
    • The workflow rules define what will trigger an action by the system (i.e. change of a certain value)
  3. When should the rule be evaluated?
    • Inserting a new record
    • Editing a record
    • On change of value of a specific field
  4. When should action be taken?
    • Removed
    • Request of event
    • Request of room
    • Request of equipment item or service
  5. What action should be taken? Actions include:
    • Require approval
    • Send email
    • Call an additional workflow rule (room/resource WF or other events WF) or action


Workflow 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 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 it 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?

Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.