Differenze tra le versioni di "Workflow configuration steps - Introduction"
| Riga 37: | Riga 37: | ||
|- | |- | ||
| − | | | + | |Requester || ''static'' || Assigned to a ‘‘[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' |
|- | |- | ||
| − | |resource || ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' | + | |Resource || ''static'' || Assigned to a ‘‘[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' |
| + | |- | ||
| + | |Project manager|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' | ||
| + | |- | ||
| + | |Manager|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' | ||
| + | |- | ||
| + | |Administrator|| ''static'' || Assigned to a ''[[Glossary|User]]'' inherited by a ''[[Glossary|resource]]'' | ||
| + | |- | ||
| + | |Assegnee|| ''dynamic'' || ''[[Glossary|resource]]'' that has assigned a ''[[Glossary|ticket activity]]'' | ||
| + | |- | ||
| + | |Creator|| ''dynamic'' || ''[[Glossary|resource]]'' that create a ''[[Glossary|ticket ]]'' | ||
| + | |- | ||
| + | |Master SG Member|| ''dynamic'' || ''[[Glossary|resource]]'' included in ''[[Glossary|Master Solution Gruop ]]'' | ||
| + | |- | ||
| + | |Master SG Manager|| ''dynamic'' || Manager of ''[[Glossary|Master Solution Gruop ]]'' | ||
| + | |- | ||
| + | |OU Manager|| ''dynamic'' ||Client ''[[Glossary|Organization Unit ]]'' manager | ||
| + | |- | ||
| + | |Owner|| ''dynamic'' ||''[[Glossary|resource]]'' responsible for the ticket ''[[Glossary|ticket ]]'' | ||
| + | |- | ||
| + | |SG Manager|| ''dynamic'' ||Manager of ''[[Glossary|Solution Gruop ]]'' | ||
| + | |- | ||
| + | |Solution group member|| ''dynamic'' || ''[[Glossary|resource]]'' that belong to ''[[Glossary|Solution Gruop ]]'' | ||
| + | |- | ||
| + | |TA SG Manager|| ''dynamic'' || Manager of ''[[Glossary|Solution Gruop ]]'' assigned to ''[[Glossary|ticket ]]'' | ||
| + | |- | ||
| + | |Third level solution group|| ''dynamic'' || ''[[Glossary|resource]]'' that belong to ''[[Glossary|Third Solution Gruop ]]'' | ||
| + | |- | ||
| + | |Ticket requester|| ''dynamic'' || ''[[Glossary|resource]]'' that has been marked as requester into ''[[Glossary|ticket ]]'' | ||
| + | |- | ||
| + | |Ticket worker|| ''dynamic'' || ''[[Glossary|resource]]'' that has in charge the ''[[Glossary|ticket ]]'' | ||
| + | |} | ||
| − | |||
=== Define a Transition === | === Define a Transition === | ||
Versione delle 15:01, 13 ago 2015
Indice
Introduction
What is a workflow? is a process applied to a Service. Two main information’s we need to know when we speak about a workflow:
- Process implemented
- Services enabled.
What is a process? A process is characterized by statues linked each other with transitions. Each transition can implement rules, transition rule, that enable the user to perform or not this transitions. User interact with a process using an interface, form, and each field of the form can be used to compose a logical rule condition.
Before starting to create a new Workflow we should identify if there is a process like the one we wants to create already developed on the system. If yes, we can add our service to an existing workflow.
If the our process has statues or form field or transition rules that are not implemented we have to create new workflow.
New process
- Each process is identify by a type. itmSUITE® call it Ticket type.
- Second step we need to think about status Workflow status
- Third, we need to think how Workflow status are connecting. Is only a one direction transtion, from status A to B, or we can came back to A, bidirectional transition.
- Fourth, once arrived in B we would like to towards C or B is Final Status?
Once we have drawn our process we have to think which Resource , or better witch Role can be enabled to execute the transition, Then we can design the Form and give a grant to the Resource.
Workflow Roles
At workflow level a user can be configure with 18 roles. Roles can be:
- Static , Application Level type
- Dynamic , Project / Service or Workflow roles type
Static Role are the once assigned to the user, Dynamic role are configured to the resource due to is belonging to a Service or a Solution Group or a Client Organization Unit or because the resource act as Creator of Ticket
Here below the table with the role description:
| Role | Type | Note |
|---|---|---|
| Requester | static | Assigned to a ‘‘User inherited by a resource |
| Resource | static | Assigned to a ‘‘User inherited by a resource |
| Project manager | static | Assigned to a User inherited by a resource |
| Manager | static | Assigned to a User inherited by a resource |
| Administrator | static | Assigned to a User inherited by a resource |
| Assegnee | dynamic | resource that has assigned a ticket activity |
| Creator | dynamic | resource that create a ticket |
| Master SG Member | dynamic | resource included in Master Solution Gruop |
| Master SG Manager | dynamic | Manager of Master Solution Gruop |
| OU Manager | dynamic | Client Organization Unit manager |
| Owner | dynamic | resource responsible for the ticket ticket |
| SG Manager | dynamic | Manager of Solution Gruop |
| Solution group member | dynamic | resource that belong to Solution Gruop |
| TA SG Manager | dynamic | Manager of Solution Gruop assigned to ticket |
| Third level solution group | dynamic | resource that belong to Third Solution Gruop |
| Ticket requester | dynamic | resource that has been marked as requester into ticket |
| Ticket worker | dynamic | resource that has in charge the ticket |
Define a Transition
TBD
As example of Worflow status diagram see the image below
Form Designer
TBD
Grant Management
TBD
Enable Services
TBD
Manage Notification
TBD
