Differenze tra le versioni di "Workflow configuration steps - Statuses"

Da itm wiki.
(Etichetta: visualeditor)
 
(8 versioni intermedie di uno stesso utente non sono mostrate)
Riga 2: Riga 2:
 
''[[glossary|Workflow statuses]]'' are key components of a ''[[glossary|workflow]]'' and they generally indicate a condition of the process. For example, the status "Closed" generally indicates that the ''[[glossary|workflow]]'' occurrence is completed and no other activity can be performed.
 
''[[glossary|Workflow statuses]]'' are key components of a ''[[glossary|workflow]]'' and they generally indicate a condition of the process. For example, the status "Closed" generally indicates that the ''[[glossary|workflow]]'' occurrence is completed and no other activity can be performed.
  
''[[glossary|Workflow statuses]]'' are managed in the ''<u>Associated Op. Statuses</u>'' tab of the ''[[glossary|workflow]]'' management forms.     
+
''[[glossary|Workflow statuses]]'' are managed in the ''<u>Associated Op. Statuses</u>'' tab of the ''[[glossary|workflow]]'' management forms, which appears as in the screen below.  
 +
[[File:Statuses management form screen.JPG|left|thumb|840x840px|Workflow Statuses Management Form]]    
  
When a new ''[[glossary|workflow]]'' is created, a set of 'legacy' ''[[glossary|workflow statuses]]'' are generated. For ''[[glossary|workflows]] ''with <u>Associated Entity</u> "Ticket", the initial set of ''[[glossary|workflow statuses]]'' is the following.          
+
When a new ''[[glossary|workflow]]'' is created, a set of 'legacy' ''[[glossary|workflow statuses]]'' are generated. For ''[[glossary|workflows]] ''with <u>Associated Entity</u> "Ticket", the initial set of ''[[glossary|workflow statuses]]'' is the following.  
 
 
Type.  itmSUITE® call it ''[[Glossary|Ticket type]]''.
 
*  Status ''[[Glossary|Workflow status]]''
 
*  How ''[[Glossary|Workflow status]]'' are connecting. Is only a one direction transtion, from status A to B, or we can came back to A, bidirectional transition.
 
* Which one of the idenfied ''[[Glossary|Workflow status]]' is a Final Status?''
 
 
Once we have drawn our process we have to think which ''[[Glossary|Resource]]'' , or better witch ''[[Glossary|Role]]'' can be enabled to execute the transition. Then we can design the Form and give a grant to the ''[[Glossary|Resource]]. ''
 
 
 
=== Workflow Roles ===
 
 
 
The li
 
 
 
At workflow level a user can be configure with 17 ''[[Glossary|roles]]''. ''[[Glossary|Roles]]'' can be:
 
* Static , Application Level type
 
* Dynamic , Project / Service or Workflow roles type
 
 
 
Static ''[[Glossary|Role]]'' are the once assigned to the user, Dynamic role are configured to the resource due to is belonging to a ''[[Glossary|Service]]'' or a ''[[Glossary|Solution Group]]'' or a ''[[Glossary|Client Organization Unit ]]''  or because the resource act as Creator of ''[[Glossary|Ticket]]''
 
 
 
Here below the table with the role description:
 
  
 
{| class="wikitable"
 
{| class="wikitable"
! Role !! Type !! Note
+
! Status !! Note
  
 
|-
 
|-
|Requester || ''static'' || Assigned to a ''[[Glossary|User]]''  inherited by a  ''[[Glossary|resource]]''
+
|"Default" || This is a special status representing the condition of a process instance after its creation but before it is saved. In other words no ''[[glossary|ticket]]'' can be saved in this status. This status is used to enable configurations at creation time.
|-
 
|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 ]]''
+
|"Opened" ||  
 
|-
 
|-
|SG Manager|| ''dynamic'' ||Manager of ''[[Glossary|Solution Gruop ]]''
+
|"Closed" ||  
 
|-
 
|-
|Solution group member|| ''dynamic'' || ''[[Glossary|resource]]'' that belong to ''[[Glossary|Solution Gruop ]]''
+
|"Completed" ||  
 
|-
 
|-
|TA SG Manager|| ''dynamic'' || Manager of ''[[Glossary|Solution Gruop ]]'' assigned to ''[[Glossary|ticket ]]''
+
|"Cancelled" ||  
|-
 
|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 ]]''
 
  
 
|}
 
|}
 +
Note that ''[[glossary|user]]''s with ''[[glossary|user type]]'' 'requester' are allowed to perform ''[[glossary|workflow transition]]''s to ''[[glossary|workflow status]]''es with associated 'legacy' status "Opened" or "Closed" only.
  
=== Workflow Status ===
+
New ''[[glossary|workflow statuses]]'' can be associated to the ''[[glossary|workflow]]'' (by means of the '''ADD NEW''' command) and pre-defined [[glossary|workflow statuses]] association can be broken (by means of the '''DELETE''' command).
 
 
itmSUITE® enable the user to create how many status is needed to deploy is workflow. When the user create the workflow, the system create for him 9-legacy status:
 
 
 
* Default
 
* Opened
 
* Defined
 
* Runinng
 
* In Charge
 
* Completed
 
* Closed
 
* Reopened
 
* Cancelled
 
 
 
this status are called legacy, because the system act in a particular way when they are reached by ''[[Glossary|ticket ]]''
 
 
 
The ''[[Glossary | Administrator]]'' can create others ''[[Glossary|status]]'' that will be used to drown the desire workflow
 
 
 
=== Define a Transition  ===
 
 
 
Transition are the connection between ''[[Glossary|status]]''. Definie a transition means:
 
* select starting ''[[Glossary|status]]'' , say Defualt
 
* select ending ''[[Glossary|status]]'' , say Opened
 
* choose the ''[[Glossary|role]]'' authorized to perform this transtion, e.g. Creator
 
We can create a One-way transition or bi-directional transition.
 
 
 
Many [[Glossary|roles]] can be enabled to perform a single transition.
 
 
 
=== Form Designer  ===
 
 
 
User interact with the workflow via ''[[Glossary|Ticket form]]''. To create a Ticket form the ''[[Glossary|administator]]'' can :
 
 
 
* Identify the necessary standard field
 
* Create custom field
 
* Create Form layout
 
 
 
Form designer , think a form as a blank page, than the ''[[Glossary|administator]]'' can create Sections, and devide it in columns and compose the page inserting the fields.
 
 
 
 
 
=== Grant Management  ===
 
 
 
''[[Glossary | Administrator]]'' can keep Visible or Mandatory some field based on ''[[Glossary | Ticket Status]]''and
 
''[[Glossary | Resource role]]''
 
  
For example, ''[[Glossary | Ticket creator]]'' see the necessary fields to define an issue, but ''[[Glossary| Service desk operator]]'' that keep in charge the issue has available the first set of fields plus the once necessary to Categorize and Analyse the issue. When the ''[[Glossary | Ticket ]]'' will be completed the ''[[Glossary | Ticket creator]]'' should have the orignal set of fields plus the solution.
+
Actually ''[[glossary|workflow statuses]]'' are created and their characteristics defined in a master data table, which can be edited from '''''General/WorkFLow/Operational Statuses''''' (see also [[Workflow configuration steps - Master data|Master Data]] step).

Versione attuale delle 10:27, 4 nov 2017

Workflow statuses are key components of a workflow and they generally indicate a condition of the process. For example, the status "Closed" generally indicates that the workflow occurrence is completed and no other activity can be performed.

Workflow statuses are managed in the Associated Op. Statuses tab of the workflow management forms, which appears as in the screen below.

Workflow Statuses Management Form

When a new workflow is created, a set of 'legacy' workflow statuses are generated. For workflows with Associated Entity "Ticket", the initial set of workflow statuses is the following.

Status Note
"Default" This is a special status representing the condition of a process instance after its creation but before it is saved. In other words no ticket can be saved in this status. This status is used to enable configurations at creation time.
"Opened"
"Closed"
"Completed"
"Cancelled"

Note that users with user type 'requester' are allowed to perform workflow transitions to workflow statuses with associated 'legacy' status "Opened" or "Closed" only.

New workflow statuses can be associated to the workflow (by means of the ADD NEW command) and pre-defined workflow statuses association can be broken (by means of the DELETE command).

Actually workflow statuses are created and their characteristics defined in a master data table, which can be edited from General/WorkFLow/Operational Statuses (see also Master Data step).