Governance Transition

GovernanceTransition is used in a GovernanceWorkflow from one GovernanceState to another. The transition can change the State but also do a number of Actions before and after the transition.

Short description: Here you give a short description of the GovernanceTransition. This should be able to give the reader an overview of the Transition.

Condition: The condition will return either true or false. It uses GovernanceBoolMethod and GovernanceBoolList.

If true, then it is possible to do the transition. If false, then it is not possible to do the transition.

In some situations when the transition is not possible, the transistion will not be shown to the user.

Message Type: The following types is available:

  • Progress (bold green)
  • Alternative (green
  • Rewind (red)
  • Conclusive (dotted and orange)

There can only be one Progress message type (illustrated by the dark green arrow), all other transitions must be Alternative paths (illustrated by the green arrow). The red arrow is a rewind transition. The orange dotted arrow is the conclusive transition to the end state.

Rule to define Duration: An object is moved from GovernanceState to GovernanceState using different kinds of transitions, e.g. a GovernanceConditionalMessage. When a transition moves an object in to a GovernanceState the object will get a date set that is the limit for how long the object is allowed to be in the GovernanceState. The limit is calculated based on what the duration is set to in the transition leading in to the GovernanceState.

The date limit can be used to handle SLAs on objects. E.g. an email can be send out to the responsible of the object when the SLA is approaching or is already passed.

  • Number of days:
    • Set a specific number of days for the duration. This will be used for all objects handled by this transition.
  • Use the following Attribute
    • Use an attribute on the object to set a specific number of days for the duration. Use this to have different durations for different objects.
    • The attribute on the object will have to contain a number that can be translated into an integer.
  • Use a date attribute
    • Use a date attribute on the object to set a specific date for when the object should no longer be in the next GovernanceState. Use this to have different dates defined for different objects.
    • The date attribute will have to be in a date format.

The number of days defined in this field decides the number of days you have to finish the next state. If you have an SLA it will influence the days to finish like this:

  1. If your days from “Beginning In State” is 5 (this is set on the GovernanceWorkFlow’s attribute “Initial State Duration”), and if your SLA is a positive number 2. Then you will have 7 (5+2) days to finish the transition to next state, and the governance task will be green the first 5 days, then yellow for the next 2 days and then red until handled.
  2. If your days from “Beginning In State” is 5 and if your SLA is a negative number -2. Then you will have 5 days to finish the transition to next state, and the governance task will be green for 3 days, yellow for 2 days and then red until handled.

Actions: When doing the transition, you can define actions to be carried out either before the transition or after. When transitioning an object, sometimes it is needed that actions are done before and/or after the transition happens. E.g. an attribute needs to be filled before an object is moved from one GovernanceState to another. If this attribute needs to be filled for all objects, it is possible to set a pre action that handles this automatically.
Both pre and post attributes can handle GovernanceActionList and GovernanceActionMethod, see more on GovernanceActions.

Governance Transition – Authority

Configuration filter: You can filter on which configuration it is possible to do the transition. Base Configuration, PWS or a named configuration (this shows a list of your configurations).

Configuration execution: This makes it possible to have the transition be carried out in another configuration than the one where the transition is triggered. This can for example be used when you want the development of a process to be done in a private workspace and only have approved processes visible for the whole organization.

Authority Required: Not all users should be able to interact with all GovernanceTransitions and GovernanceStateFeatures. The options for Authority Required helps configure which level of authority the user should have in order to execute a transition or feature.

  • Everyone (Everyone authorizes everyone to do the transition.)
  • Any Role (Any Role means any GovernanceRole related or included in the GovernanceWorkFlow.)
  • Current Role (The default authority is the Current Role. This is the governance role that the state the transition is coming from is inside.)
  • Only Master Role (Only Master Role is the role you set on the GovernanceWorkflow, and you can also specify other specific roles together with the master role in the list next to the authority levels.)

Extended authentication: If extended authentication (‘digital signature’/login) is required, then it can be enabled:

  • None (No extended authentication)
  • Password Authentication (A login box with password is shown)
  • Full Authentication (A login box with full authentication is shown)
  • Allow Changed User (If the “Allow change user” is also enabled, then a login box with both user name and password is shown)

Authentication text: Is for writing a descriptive text associated with the login window.

Governance Transition – Detail

Visual Name: This will be shown as the name of the button. If this is not defined, then the name of the GovernanceTransition object will be shown instead.

Please consider how the text is formulated to help the user to know what will happen when the button is clicked.

Icon on web: An icon to show on the button. An icon can be a helpful indicator to a sighted user about what will happen on clicking the button.

Comment: An option for the user to add a comment related to the transition. This comment will be stored with other governance information about the object (it will not be a comment object). The comment can be shown in e.g. the Governance History information of the object.

  • Skip: User will not be able to add a comment.
  • Optional: User will be presented with option to leave a comment but is able to complete the transition without writing anything in the comment field.
  • Mandatory: User will be forced to leave a comment in order to complete the transition. There are no checks on the actual content of what the user writes in the comment field.

Web feature: These options will define what happens when the user clicks the transition button in the web interface.

Web Dialog: Use this option for when a webform is needed during a transition. The webform will only be able to handle the current object.

  • Customization: Use this to define which HTMLDialogLayout will be used for the webform to be opened. If left empty, the default HTMLDialogLayout or metamodel defined webform will be used.
  • Select Dialog: If checkmark is checked, it is possible to link a specific HTMLDialogLayout to be used for the webform, without using customization.
  • It is recommended to use customization for defining HTMLDialogLayout.

Web Service: This is used when you want the transition to run.

Custom script: When this is enabled, you will be able to write custom JavaScript code to be run when doing the transition. (N.B. This should be used with caution.)

Leave a Comment