Archives: Templates

A GovernanceConditionalMessage is used in a GovernanceWorkflow when you want to do a GovernanceTransition based on some event condition (GovernanceBoolList/Method).

Short description: Here you give a short description of the GovernanceConditionalMessage. This should be able to give the user an overview of the feature.

Level: Level is used to indicate the context where the conditional message is evaluated and executed:

• Object: Context is object level, i.e. the conditional message should run for each object.
• State: Context is the state of the object. A manager might want to be notified about all objects in a specific state.
• Workflow: Context is the entire GovernanceWorkflow. A manager might want a weekly update about their governance tasks related to the GovernanceWorkflow.
• Global

Event Condition: A condition for if the action(s) should run or not. The condition should return true or false with true meaning the action(s) will run.

Event Renew: This defines how often the GovernanceConditionalMessage should be repeated. The time is defined in minutes.

If Event Renew is set to 0, the GovernanceConditionalMessage will be run once the condition is met. It will be run when EventTracker is set to run.
Otherwise the Event Renew is the number of minutes from the first time the condition is met and the action(s) are executed to the next time the action(s) should be executed according to the setting for EventTracker specified on the HTMLPublisher.

E.g. EventTracker runs daily at 1am and registers that condition is met = the action will be run. If Event Renew is then set to 1440 minutes, the action will run once a day, when the EventTracker is set to run, until the condition is no longer true.

Configuration Filter: When does the condition apply – all configurations (none), base configuration, private workspace(s) or a named configuration

• None – The configuration will not be considered when evaluating the condition and executing the action(s).
• Base – Only the base configuration will be considered for evaluating the condition and executing the action(s).
• PWS – All private workspaces will be considered for evaluating the condition and executing the action(s).
• Named – Only the named configuration will be considered for evaluating the condition and executing the action(s).

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.

Action: The action(s) to be executed, if all conditions are met.

Asynchronously: If checked, the action(s) will run asynchronously.

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.)

The GovernanceStateFeature placed on the GovernanceState contains all related buttons on the web for that particular GovernanceState in a GovernanceWorkflow.

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

Condition: Should some condition (GovernanceBoolMethod/List) be true before the feature can be used/is visible.

Scope: Where does the feature apply – Only Web or QLM or both?

QLM feature: If you want a feature to be available from QLM and web (or just QLM) you need a corresponding QCL code.

Governance State Feature – 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 State Feature – 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.

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.

• New Object: When checked, a new object will be created. When not checked, the current object will be opened for editing.
• Create In memory object:
  • Template: Used in combination with the New Object checkmark. Specifies the Template to use for the new object.
  • Link: Used in combination with the New Object checkmark. Specifies how the new object will be link to 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.)

The GovernanceState is used in a GovernanceWorkflow to specify the status of the object. (It is similar to the previously used ApprovalState in older QualiWare versions.)

Type: A state can either be a start (light blue), intermediate (yellow) or end state (blue). There can only be one start and one end state on the governance diagram.

Transient System Flag

Check Code: If you want some condition/behaviour to be present before going into the state then you can create a check code using a GovernanceActionList or -GovernanceActionMethod.

Skip warning messages: If the GWE gives a warning message, you can bypass it (ignore it).

Signatures Needed: If you set signatures to two, then two users have to choose the transition (e.g. approve the process). When a user has done the transition then the option will disappear, but it will not do the actual transition before all required ‘signatures needed’ have signed (chosen the transition).
N.B. Keep in mind if you configure so there is only one participant for that particular governance role, then the process will be stuck if two signatures are required.

State behavior: If you don’t want the object in this state to be shown in the governance task list, then you should choose “Sleeping” in the dropdown box. Per default “Workflow” is set which means it will be shown in the governance task list.

Service level agreement: SLA is used in combination with the transitions ‘rule to define duration’. (See Governance Transition)

Legacy Control: If previous ApprovalState or other status field has been used this can make sure they follow the new governance workflow.

Governace State – Features

While an object is in a GovernanceState, different things can be done to the object. E.g. in Development GovernanceState it is usually possible to edit the attributes of the object. It is also possible that the object exceeds the allowed time it can be in the GovernanceState. These actions and event are handled by what is linked in State features.

For each state you can define what features and events should be available. This is defined by inserting the required features in the list:
• GovernanceStateFeatures (defines buttons/actions),
• GovernanceConditionalMessage (defines automatic transitions)
• GovernanceEventMessage (events).

Governace State – Required Actions (introduced in QualiWare 10.8)

Required Actions: Here you can insert a description, that should guide the user on the web, explaining which required actions they should do. The text will be shown when they open their “To Do” on the web.