Navigation:  User Manual > System Configuration >

Workflow templates

Previous pageReturn to chapter overviewNext page

In the workflow management system it is possible to act, with regards to the configuration, through the following levels:

1.Definition of the default statuses
2.Definition of the templates of the workflow processes, through the aggregation of default statuses or new statuses created by necessity.

 

Default statuses

It is possible to define some default statuses, each one with its own characteristics. Such default statuses could then be aggregated in templates of workflow processes. For each default status it is possible to define:

A title and a description
Some "flags" which define what activities can be performed on the contents during such status, i.e. if they can be modified, reviewed, distributed
One or more activities (of development and/or reviewing) that the workflow engine will create in the reference project
For each of the activities, who (in terms of system roles) should perform such activities (for example the activities of development of an animation will be assigned to graphic designers while the development of the LOs to Instructional designers and so on).

 

Templates for the workflow processes

The system allows the creation of an indefinite number of templates for the workflow processes. A workflow process is composed of:

A series of steps which can be changed by the default steps or created from scratch
Some step-out rules from a status to another according to a series of criteria such as:
Possible pre-conditions of the activities created by a step
Rules of automatic progress of the workflow (when the activity 1 is complete, go to step "X")
Rules of manual progress of the workflow, linked to one or more user roles (when the activity 2 is complete, the users with a "Project Manager" role can go to step "Y" or "Z")

 

Both status and workflow processes reside in the Digital Repository and can be created and modified through an appropriate web interface.

A typical process to set-up and adopt a workflow process for the development of a digital content object can be summarised in the following steps.

1.        Preliminary system configuration, consisting in:

1.1.        Creating user roles

1.2.        Creating content types (this activity can also be done later and is addressed below)

1.3.        Creating default workflow steps, which consists of:

1.3.1.        Editing step properties

1.3.2.        Defining user roles best fitting step duties

1.3.3.        Defining the “Activities” that will be created by each step

2.        Creating workflow templates by:

2.1.        Editing template properties

2.2.        Adding (existing or new) steps to the chain

2.3.        Customising where needed the chained steps, meaning:

2.3.1.        Editing step properties

2.3.2.        Defining user roles best fitting step duties

2.3.3.        Defining the “Activities” that will be created by each step

2.3.4.        Defining for each step the “step-out rules”

3.        Publishing content templates and metadata profiles to the system

4.        Setting up content types, meaning:

4.1.        Editing content type properties

4.2.        Associating to each content type the appropriate:

4.2.1.        Content templates

4.2.2.        Metadata profiles

4.2.3.        WF templates

Now the system can be considered “configured”, meaning that it is ready to be used for content authoring and publishing activities.

 

An example of the configuration described above can be summarised as in the following tables:

The system has (amongst the others) these USER ROLES:

ROLE “Developer”

Has the following permissions

-Can publish new content objects
-Can use the web editor
-Can comment on material

ROLE “Reviewer1”

Has the following permissions

-Can create comments
-Can comment on material

ROLE “Reviewer2”

Has the following permissions

-Can create comments
-Can comment on material

ROLE “PM”

Has the following permissions

-Can manage projects
-Can manage tasks
-Can assign tasks
-Can create comments
-Can comment on material

ROLE “QA Leader”

Has the following permissions

-Can manage tasks

 

The system has (amongst the others) these possible WORKFLOW STEPS:

Draft editing

Has the following properties

-Editing is allowed
-Reviewing is not allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act1 (Developer)

Internal review

Has the following properties

-Editing is allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act2 (Reviewer1)
-Act3 (Developer)

External review

Has the following properties

-Editing is not allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act4 (Reviewer2)

Final tuning

Has the following properties

-Editing is allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act5 (Reviewer2)
-Act6 (Developer)

Formal approval

Has the following properties

-Editing is not allowed
-Reviewing is not allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act7 (QA)

Release

Has the following properties

-Editing is not allowed
-Reviewing is allowed
-Delivery is allowed

Creates the following activities (each one with target roles)

-

Based on these roles and these steps, the system has (amongst the others) the “Default WF” WF Template.

The WF Template consists in the following steps:

1.Draft editing
2.Internal review
3.External review
4.Final tuning
5.Formal approval
6.Release

Where:

Draft editing

Has the following properties

-Editing is allowed
-Reviewing is not allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act1 (Developer)

Has the following rules

-PM can go to any step except “Release”
-Goes to “Internal review” when “Act1” is completed

Internal review

Has the following properties

-Editing is allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act2 (Reviewer1)
-Act3 (Developer)

Has the following rules

-PM can go to “Draft editing” at any time
-When “Act2” is completed, PM can go to “External review”, “Final tuning” or “Formal approval”
-Goes to “External review” when “Act2” and “Act3” are completed

External review

Has the following properties

-Editing is not allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act4 (Reviewer2)

Has the following rules

-When “Act4” is completed, PM can go to “Draft editing”, “Internal Review” or “Final tuning”

Final tuning

Has the following properties

-Editing is allowed
-Reviewing is allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act5 (Reviewer2)
-Act6 (Developer)

Has the following rules

-PM can go to “Draft editing” or “Internal Review”
-When “Act5” is completed, PM can also go to “Formal approval”
-When “Act5” and “Act6” are completed, goes to “Formal approval”

Formal approval

Has the following properties

-Editing is not allowed
-Reviewing is not allowed
-Delivery is not allowed

Creates the following activities (each one with target roles)

-Act7 (QA)

Has the following rules

-QA can go to “Release” or to “Internal review”

Release

Has the following properties

-Editing is not allowed
-Reviewing is allowed
-Delivery is allowed

Creates the following activities (each one with target roles)

-

Has the following rules

-PM can go to any step except “Formal approval”

 

Given what above, for each step the possible target steps are reported in the table below:

Target

Current

Draft editing

Internal review

External review

Final tuning

Formal approval

Release

Draft
editing


-PM
-Act1
-PM
-PM
-PM
-none

Internal
review

-PM

-(if Act2) PM
-(if Act2) PM
-(if Act2) PM
-none

External
review

-(if Act4) PM
-(if Act4) PM

-(if Act4) PM
-(if Act4) PM
-none

Final
tuning

-PM
-PM
-none

-Act5+6
-(if Act5) PM
-none

Formal
approval

-none
-QA
-none
-none

-QA

Release

-PM
-PM
-PM
-PM
-none

 

The system has several Content Types, several Content Templates and several MD Profiles. In particular it has the Content Type “Course” which is configured as in the following table:

Content type

WF Template

MD Profiles

Content Templates

Tutorial LO

Default WF Template

-IMS 1.2 Basic
-IMS 1.2 Advanced
-SlideShow
-MLB
-GLREV

Now, the authoring and publishing activities will make use of the WF processes in the following way:

5.        Assigning to a content object the most appropriate WF template amongst the ones associated to the content type, where the content type is associated to any of the following paths:

5.1.        Choose a Content type, then create a new content object using one of the content templates associated to it, or

5.2.        Assign a Content type to an object published to the repository

6.        While assigning the WF Template, the user will also define the “working project” for the WF instance of the material

7.        Users who give any contribution to the content object will act in the framework of the assigned WF template, meaning that:

7.1.        Users who author the content object will be using the assigned content template

7.2.        Users who edit the metadata of the new content object will be using one of the MD Profiles associated to the related content type

7.3.        The possibility for a user to step out of a WF step will depend on matching WF rules