Start page
Start page
Online Documentation

Start page / Templates (basics) / Composition of templates / Workflows

Structure of workflows

A workflow is a sequence of tasks that is completed according to a fixed, predefined structure. In FirstSpirit, due date deadlines and groups of authorized individuals can be defined for the respective tasks.

Project-specific workflows can be created using a graphical editor. Instances of these workflows can then be started in context on each element in a FirstSpirit project or, if there is no context, using the FirstSpirit menu bar (for an explanation of the difference between “context-free” and “context-oriented” refer to below). Each instance of a workflow has to run according to the rules set in the workflow.

Overview of open workflows

At the “Workflows” root node in the Template Store, there is an overview of all the workflows (instances) open in a project. The overview also allows the view to be filtered according to different search criteria. Tasks can be edited and closed again in the overview.

Templates tab

There are various tabs in the SiteArchitect workspace for each workflow. These tabs can be used to configure all the settings and definitions required to model a workflow:

  • Properties tab: Valid settings for the workflow are defined here.
  • State diagram tab: A workflow can be modeled using a graphical editor. This page also presents important rules for modeling workflows.
  • Form tab: Input components for entries within workflows are defined here.
  • Rules tab: Rules can be defined to control elements or properties.
  • Snippet tab: How the workflow is displayed in overview lists can be defined here.

Further topics

The procedure for using workflows is described in later Chapters.

  • Write protection: Write protection can be applied to objects within a workflow that must not be edited.
  • Error handling: In order to reliably catch errors and prevent an instance of the workflow from being in an inconsistent state after switching a transition, an optional error state is available in the modeling for workflows.
  • Using scripts: Scripts make it possible to implement complex functions in a project.
  • Deletion via workflows: A project-specific workflow can be created and directly connected to the control elements for deleting elements.
  • Multiple selection: The multiple selection of workflows allows a workflow to be started and switched for an entire set of objects.
  • Permission configuration: FirstSpirit offers a flexible feature for defining very precisely which user is permitted to perform a particular workflow step. Before a workflow can even be started, appropriate permissions must have been defined for the transition. In the case of context-dependent workflows, relevant permissions also have to be granted for the node/subtree/store from which it will be possible to start the workflow.
    For further information on workflow permissions, see Chapter “Advanced topics”.
  • Further information on creating workflows can be found in the Chapter Tutorials.

Integrated workflows

There are two workflows already integrated into FirstSpirit:

  • Release request: This is an integrated workflow for releasing objects. It is a context-oriented workflow that is linked to a specific object. As a result, it can only ever be started and run in relation to this particular object.
  • Task: This is an integrated workflow for assigning tasks. It is a context-free workflow, which means it is not linked to a specific object. Therefore, it can be started “out of context”, i.e. without reference to a particular object.

Access via the FirstSpirit API

Workflows can be accessed via the FirstSpirit API by means of the following entry points:

Print version | Page start

© 2005 - 2015 e-Spirit AG | All rights reserved. | Last change: 2014-07-16