Chapter 1: Introduction

Workflow in Sitellite is governed by a few basic concepts. When an action occurs in Sitellite (ie. a document being saved), it is called a workflow event. When an event occurs, one or more services are triggered in reaction to it. An example of a service would be the task of emailing a new pending document notice to a site editor. These services are provided in the form of ordinary Sitellite boxes. Which services to trigger for which events is determined by a series of configuration files in the inc/app/cms/conf/services folder in your Sitellite installation.

The Sitellite boxes triggered by workflow events accept certain standardized parameters specific to workflow, and additional parameters specific to the type of even that was triggered. For example, all services will receive the $parameters['transition'] variable, while the "add" and "edit" services also receive $parameters['collection'], $parameters['data'], and several others as well. Instructions for what parameters are expected for a particular service handler should be included in the box's settings.php file.

You can configure any number of event types, but the built-in events include:

• login
• logout
• add
• edit
• delete
• error

In addition to the ordinary event configuration files, there is a global.php event file, which triggers the services listed within for any event type except "error". This way, services such as an activity log can be listed only once and be called automatically for any event type, including new ones that are added later on.

The event configuration files aren't managed directly, however, but rather they are managed exclusively via the "Workflow Services" form under Sitellite's Admin tools. Services made available by all Sitellite apps are auto-discovered and made available on that screen.

An example would help to illustrate how this all works together.