Workflow Server

För företag och organisationer som har behov mer komplexa regler för dokumenthantering, exempelvis ärendehantering eller annan processtyrning, finns Content Studio Workflow Server. Produkten gör det möjligt att skapa informationsflöden som bygger på roller, att-göra-listor, seriella eller parallella flöden, dynamiska flöden styrda av villkor och innehåll etc.

I ett klassiskt arbetsflöde passerar informationen/ärendet ett antal olika steg eller dokumentstatus, exempelvis Nytt ärende, Under analys, Under åtgärd, Åtgärdat och Avslutat. I Content Studio Workflow Server kan ett godtyckligt antal steg definieras och för respektive steg kan arbetsuppgifter utdelas till medarbetarna. Content Studio Workflow Server hanterar automatiskt all notifiering, behörighetskontroll och publiceringsmekanism.

Med en effektiv arbetsflödesmotor minimeras det manuella arbetet med att överföra ansvaret till "näste man i ledet", informationskvaliteten höjs och arbetet styrs upp av uppsatta regler. Rättigheter och arbetsuppgifter såsom att granska, skapa, skriva, komplettera, godkänna, bedöma eller delegera, styrs av arbetsflödet.

En arbetsflödesmotor kan implementeras effektivt inom ett antal områden, exempelvis:

• Ärendehantering
• Ledningssystem
• IT-Support, Helpdesk
• Dokumenthantering
• Beslutstöd
• Inköp
• Rekrytering

Content Studio Workflow Server integreras mycket väl med EPT-tekniken i Content Studio vilket ger Workflow-medvetna redigeringsformulär. Att utveckla exempelvis ett ärendehanteringssystem är betydligt enklare med Workflow Server än med traditionell programmering.

Sätta upp arbetsflöde

Att skapa ett arbetsflöde i Content Studio består sammanfattningsvis av följande moment:

• Skapa en arbetsflödesdefinition (Workflow Definition)
• Applicera definitionen på önskad dokumentkategori.
• Om kategorin är av typen EPT-dokument kan redigeringsformuläret kompletteras med Active Scriptingkomponenter som interagerar med arbetsflödesmotorn.

Definitioner och terminologier

Nedan följer en kort beskrivning av flödesdefinitioner och terminologier.

Workflow definitions

A workflow definition defines the workflow itself. It contains a large number of settings and parameters that describes all steps, roles, rules etc. Workflow definitions (WF Definitions) are stored in a central repository accessable for administrators. Normally only administrators can create/edit workflows.

WF Definitions can be applied on one to many document categories:

Workflow implementation

A workflow implementation is a connection between a workflow definition (above) and a XML document category in Content Studio. When a category has been configured to utilize a workflow (ie. workflow definition), all new documents or revisions in the category will use the selected workflow.

Workflow instance

When a new document is created, or when a new version of a document is created, a workflow instance will be applied to the document. The workflow instance is a copy of the workflow definition combined with information about the document, the category and the roles and members defined on the category. The workflow instance will be attached to the document until the workflow completes or terminates. All information about user actions and content changes is stored in the workflow instance.

Roles

A central definition in a workflow definition is Roles. Roles can contains a number of member (users) who can participate in the workflow process and perform different tasks. Typical roles are 'Authors, 'Reviewers' and 'Approvers'. Members in roles, ie users, can be defined in the definition itself or on the category implementation, or be selected by the workflow owner.

Roles (and their members) are later assigned to the workflow steps.

Members

Users defined in a role are called Members. Members can participate in workflow steps and perform different tasks.

Participants

Users who actually participate in a certain step, and therefore have tasks assigned on them, are called participants. Participants are normally defined as members, but in some workflows participants can be selected by the workflow owner.

Steps

The steps section in a workflow definition is probably the most important part of the workflow. A workflow normally consists of 3-5 steps describing the process in which content is created, reviewed, modified, approved and published. Typical steps are 'Authoring', 'Reviewing' and 'Approve'. In a workflow you can define as many steps as you need.

Types

Steps can be of 3 types:

• authoring - participants can edit content
• reviewing - participants can review content and normally not edit content (configurable)
• approval - participants can approve/reject content and normally not edit content (configurable)

When you design a workflow you can define any number of steps and you can create step sequences that combines authoring, reviewing and approval.

Document Status

When a step starts, completes, is cancelled or due, the workflow status changes to the value defined in the definition. Typical statuses are 'New version', 'Sent for authoring', 'Authored', 'Sent for review', 'Reviewed', 'Sent for approval', 'Approved' and 'Rejected'. Document status are defined using the attributes csbeginstatus, cscancelstatus, csduestatus, csdeclinestatus, cscompleteyesstatus, cscomletenostatus

Completion rules

A step has always a completion rule defining when the step is considered as complete. Completion rules includes

• all - all participants must complete their task
• X % - X % of the participants must have completed their task
• X - X of the participants must have completed their task

If the completion rule is forfilled, the step result will be completed. Normally the step result is evaluated everytime a task status changes and therefore the step can be completed BEFORE all participants have completed their tasks.

If evaluation should occur AFTER all participants have completed/declied their tasks, the 'allmustparticipate' setting can be used.

Step result

When a step has been run the result will be set to any of the following:

Serial or parallell flow

Tasks assigned in a step can be assigned to participants in parallell or in serial:

• Parallell - all participants will receive their task/notification at the same time.
  + fast task assignment and faster response
  - Risk of task-SPAM depending on rule
• Serial - participants will receive their task/notification when the previous participant has completed or declined their task
  + Accurate task assignment independent of rule
  - Slow task assignment

Selectable members

Members participating in a role applied to a step, can be predefined or selectable by the workflow owner. This is configured in the 'selectable' tag:

• no - participants cannot be selected by the workflow owner. Only default role members will participate
• yes, a role member - a single member of the role can be selected
• yes, role members - any number of members of the role can be selected
• yes, a user - a single domain user can be selected
• yes, users - any number of domain users can be selected

Runs

The steps defined in the workflow can be executed more then once depending on the rules in the workflow.

Each time a step is started, a new Run is created. The Run contains information about participants, tasks, due dates, task instructions and more.

The Run segment of the Workflow definition is empty when the instance is created. Before a step is started, the Runs segment is created and filled with run-data.

Tasks

Tasks are "to-do-items" attached to steps and participants. In a step, a participant can have a task assigned on him/her. The participant is normally notified by either mail or by the integrated to-do-list in CS.

When a participant completes or declines the task, or when the task is due or the step cancelled, the step result is evaluated according to the Completion rule.

Notifications

CSWF integrates with the CS Notification Engine by automatically sending to-do items to step participants. The notifications sent by CSWF contains customizable titles/messages for each step which gives the workflow designer the possibility to create pedagogical notifications. The messages sent can be built up by both static and dynamic content. For dynamic content CSWF supports a large number of variables and constants.

When a task has been completed it will automatically be removed by CSWF from the to-do-list.

Workflow Owner

Every workflow instance is owned by a user. In CSWF this user is called the Workflow Owner, or wfowner. Normally the wfowner is set to the document owner (creator) when the document is created, but the wfowner can be changed by the wfowner himself, by the administrator or by workflow logic. For example, the wfowner can be changed when a step starts and the ID of the owner can be defined in the XML.

Normally, the wfowner controls the workflow and have permission to withdraw or cancel steps. The wfowner can also terminate the workflow. The workflow owner can have permission to pick step participants.

Enabling/disabling steps

Steps is normally enabled and accessable for the wfowner. An enabled step can be started by the wfowner. In complex workflows a more controlled flow can be set up using the 'enablinglogic' step setting. This setting controls how and when a step will be enabled or disabled. CSWF evaluates the content of the enablinglogic setting and if the result is True, the step will be enabled.

WFXML

For XML-documents managed by a Workflow a number of new CS XML-tags will be added and updated during the workflow cycle:

Workflow settings

General workflow settings can be set using the wfsetting attribute:

• adminsetwfowner - an administrator can change workflow owner
• keepwfowner - the workflow owner will remain between document revisions
• ownersetwfowner - the current workflow owner can change workflow owner
• singlerevisiononly - only one document version is allowed.
• mailonwfownerset - a mail will be sent to the new workflow owner when ownership is changed

Steps settings

For each step in the workflow different settings may be applied using the stepsettings attribute (multiple values must be comma separated):

• approverscanedit - in an step of type approval, the participants can edit content
• allmustparticipate - in a serial flow, all participants will participate even if the step completion rule has determined that the step result is negative or the step is declined
• ownercanedit - owner can edit even thought the workflow is in a review or approval stage
• returnandcompleteondue - if the step is due (timeout) the step will automatically be completed (yes)
• returnandrejectondue - if the step is due (timeout) the step will automatically be rejected (no)
• returnondue - if the step is due (timeout) the document will be returned (User action returntowfowner)
• copyparticipantsfromlastrevision - participants in the step will be kept between reviwions
• copyparticipantsfromlastrun - participants in the step will be kept between runs
• csapprove - if the result of the step is completed yes, the document will be approved (and published) in content studio. The workflow will also be completed.
• autocomplete - the step will automatically complete, approval step type not supported
• ownersetwfowner - the current workflow owner can change workflow owner
• reviewerscanedit - in a step of type reviewing, the participants can edit content

User actions

During a workflow the client (user) can perform different tasks that affects the workflow status and flow. These tasks are called User Actions and are executed through Active Scripting components such as the WF Button component and the API.

• terminateworkflow - this action will terminate the workflow. The action is only available for the wfowner (and the administrators)
• sendforauthoring - the workflow will initialize a step of type authoring. The action is only available for the wfowner and when no step is active.
• sendforreview - this action will initialize a step of type review. The action is only available for the wfowner and when no step is active.
• sendforapproval - this action will initialize a step of type approval. The action is only available for the wfowner and when no step is active.
• cancelauthoring - this action will cancel a running step of type authoring. The action is only available for the wfowner and when an authoring step is running.
• cancelreview - this action will cancel a running step of type review. The action is only available for the wfowner and when a review step is running.
• cancelapproval - this action will cancel a running step of type approval. The action is only available for the wfowner and when an approval step is running.
• returntowfowner - this action will complete a task. The action is only available during a running step and only available for step participants that has NOT completed their task.
• reject - the action will complete a task with a negative response (=reject in approval steps). The action is only available during a running step and only available for step participants that has NOT completed their task.
• approve - this action will complete a task with a positive response (=approve in approval steps). The action is only available during a running step and only available for step participants that has NOT completed their task.
• decline - this action will decline a task (=refust). The action is only available during a running step and only available for step participants that has NOT completed their task.
• setparticipants - this action will set participants for a certain step. The step may not be running.
• changewfowner - this action will change wfowner. The action is only available for the current wfowner (and administrators if the workflow setting adminsetwfowner is used)

Workflow definition details

Below is a description of the xml-tags in a typical workflow definition. Some of the details are set when the workflow is instanciated and used and are read-only. Read-only items are in gray.

Workflow Section

This section defines general workflow settings

Roles section

This section defines roles and their default members.

Members section

The members section are part of each role section. One or more member can be defined. Note that additional members can be added in the category on which the definition is applied.

Steps section

The steps section defines a number of steps. A step can be be an authoring step, a reviewing step or an approval step.

The steps definition is probably the most important and complex part of a workflow definition.

Steproles section within a <step>

Evaluation logic

The step tag 'enablinglogic' is a powerful mechanism for creating dynamic workflow. By using the evaluation logic, steps can be enabled and disabled depending on

• Completed steps
• XML-content
• User roles
• Other Workflow data

For the step to be enabled, the expression in the enablinglogic tag must be evaluated with a result different from False, 0 and blank. If it returns a value of True or anything else but the those mentioned, the step will be enabled and available for the workflow owner.

Expressions and functions

Logical operators

• comparison: > < <> = <= >= (work also on strings)
• logical: and or xor not

Examples

• not [@memberofrole('editors')]
• not [@stepcomplete('Review')]
• ([@stepcomplete('QA')]) and ([@stepcomplete('Review')] or [@memberofrole('editors')])
• $ept_cost>2000
• '$ept_company'='Teknikhuset'

Constants, variables and functions for messaging

Using notifications and the workflow engine, messages can be sent using the internal messaging system and/or e-mail. When setting up the messages, the following constants can be used: