Configure Workflows and Change Requests
Configure the behaviour or workflows and change requests when users create or modify Axon objects.
Create a Default Workflow
You can configure Axon to use a default workflow when users create or modify objects. You can specify a default workflow for a facet, and Axon uses the default workflow whenever users create or modify objects for the facet.
You must have a SuperAdmin profile to create a default workflow.
For more information on workflows and change requests, see the Workflows and Change Requests chapter in the Axon Data Governance 7.1 User Guide.
1. From the Axon toolbar, click Admin Panel under the user name.
The Admin Dashboard appears with the Axon version details, status of Axon services, and Axon message queues.
2. On the left navigation pane, click DG Operating Model > Default Workflows.
3. Select the facet for which you want to configure a default workflow.
4. Choose to add a new workflow.
5. Enter a name for the workflow.
The name must contain a minimum of six characters.
6. Provide a description for the workflow.
Axon creates a canvas with many swimlanes based on the roles that are defined for the facet.
7. In Workflow Diagram section, create a workflow diagram on the canvas. Create swimlanes to assign tasks to the facet stakeholders or Requestor. Use the Toolbar to add objects and connect them. Use the Properties panel to specify additional properties for the objects.
8. In the workflow diagram, specify the required fields for the following items:
- - User Task. You need to enter a name and due date for a user task.
- - Exclusive Gateway. Specify short, unique labels for the lines that start from an exclusive gateway. The labels serve decision routing actions when you run the workflow. A gateway and the preceding user task must be close to one another in the same swimlane because they both are a logical unit and must be performed by the same user.
9. Click Save.
Workflow Designer
Axon implements a visual editor to create and run a workflow from a browser.
When you provide a name and description for a new workflow, Axon creates a canvas to create a workflow diagram. The Workflow Diagram section has three components: a toolbar on the left, a canvas in the center, and a properties panel on the right.
The following image shows the different sections of a workflow diagram:
- 1. Toolbar
- 2. Canvas
- 3. Properties
Toolbar
Use the toolbar to create a workflow diagram. The toolbar has three sections. The top section contains tools to select the items, resize the canvas, and connect the items. The middle section lists the building blocks of the workflow. You can select the items and drag to the canvas to create the workflow. The bottom section contains tools to show or hide the toolbar.
The following table describes the different tools that you can use to create a workflow diagram:
Tool Name | Description |
---|
Hand | Use the hand tool to select an item. |
Lasso | Use the lasso tool to select a block on the swimlane. |
Create/Remove Space | Use the create or remove tool to increase or decrease the canvas size. |
Global Connect | Use the global connect tool to connect the items in a workflow. |
Create StartEvent | Use the Create StartEvent tool to start a workflow event. You can decide the role that can start the event. |
Create EndEvent | Use the Create EndEvent tool to end a workflow event. You can decide the role that can end the event. |
Create ExclusiveGateway | Use the Create ExclusiveGateway tool to create decision boxes that can have two results. For example, a validate request can have two values: accept and reject. A gateway and the preceding user task must be close to one another in the same swimlane because they both are a logical unit and must be performed by the same user. |
Create UserTask | Use the Create UserTask tool to create tasks that a user can perform. You can enter a name, due date, and description for a user task. You can create user tasks such as validate request, capture impact assessment, confirm feasibility, and approve request. |
Create Pool/Participant | Use the Create Pool or Participant tool to add a swimlane for a user role. |
Upload BPMN | Use the Upload BPMN tool to upload a workflow diagram to the canvas. |
Download BPMN | Use the Download BPMN tool to download a workflow diagram from the canvas. |
Hide/Show | Use the Hide or Show tool to hide or show the toolbar. |
Canvas
The canvas provides a visual representation of the workflow. When you create a custom or default workflow, Axon automatically creates an empty canvas with swimlanes for each role that is defined for a facet. For example, if a Glossary facet has four roles, Axon creates four swimlanes, one for each role.
Select a swimlane and drag a corner to resize the canvas vertically and horizontally. Select items from the toolbar, drag them to the canvas, and connect them. When you place an item on the canvas, you can click the item to view the toolbar options that are relevant to the object.
BPMN workflows use swimlanes to capture who is responsible for a set of tasks. The tasks that you specify in a swimlane becomes the responsibility of the role associated with the swimlane. If one or more roles do not contain any task in the workflow, you can leave the swimlanes empty or delete the swimlanes. If you want to create the swimlane again, you can use the tool bar to create a swimlane and you must specify the role name and the correct role ID.
Properties
In the Properties panel, you can specify additional properties for the items or tasks on the canvas. The properties that appear depend on the tool that you add to the workflow. All properties do not appear for all tools.
The following table describes the properties that you can configure:
Tool Name | Description |
---|
Name | Name of the workflow step. If you click a role in the workflow canvas, select the object stakeholder or requestor that participates in the workflow step. |
Due Date | Date by which the workflow step must be completed. |
Description | Description of the workflow step. |
Axon Status | Status of the object during the workflow step as it appears in the Axon Status field. |
Lifecycle | Lifecycle of the object during the workflow step as it appears in the Lifecycle field. |
Unlock Object | Select the check box to unlock the object at a specific step in the workflow. If you do not select the check box, the object remains locked. |
Commit Changes | Select the check box to save the object with the changes and apply the values that you specified in the Axon Status and Lifecycle fields. This check box is typically selected when the workflow has reached the last step and a stakeholder has approved the changes to the object. Clear the check box to not save the object. This check box is typically cleared when the workflow has reached the last step and a stakeholder has rejected the changes to the object. |
If you have a gateway in a workflow, you must specify the labels for the lines that start from the gateway. The labels need to be short and unique. The labels serves decision routing actions when you run the workflow.
Predefined Workflows
Axon has predefined default workflows for each facet. You can use these sample workflows to build your own workflows.
To view the predefined workflows from the Admin Panel, navigate to DG Operating Model > Default Workflows and select a facet. For each facet, you can view a sample predefined workflow. When you select the predefined workflow, Axon displays a canvas with the sample workflow for the facet.
The workflow diagram is spread across the swimlanes based on the roles that are defined for the facet. The swimlanes appear with a lane for each type of stakeholder role configured for a facet. For example, the Glossary facet has Glossary Steward and Glossary Definition Owner roles and the predefined workflow diagram is spread across both the lanes. The Business Area facet has Business Area Head role and the predefined workflow is present in a single lane. You can find an additional requestor swimlane in the diagram. A requestor can be any user in the organization, including users that are not stakeholders for a facet, who raises a change request.
The predefined workflow name is in the following format: DefaultWorkflow-n-FacetName. For example, if the Glossary facet has two stakeholder roles, the predefined workflow name is DefaultWorkflow-2-Glossary. If the Business Area facet has one stakeholder role, the predefined workflow name is DefaultWorkflow-1-BusinessArea.
Consider that you select the predefined workflow for the Glossary facet. The rest of the fields are automatically populated.
The following image shows the predefined workflow selection for the Glossary facet:
You can see the predefined workflow tasks spread across two swimlanes in the Workflow Diagram section. The task starts and ends in the Glossary Steward swimlane. The Glossary Definition Owner swimlane includes a decision-making task.
The following image shows the workflow diagram for the Glossary facet:
- 1. Requestor
- 2. Glossary Steward
- 3. Glossary Definition Owner
In the Glossary workflow diagram, you can see that the steward creates a glossary term and sends the term to the definition owner for approval. If the glossary term is approved, the steward ends the workflow after implementation. If the glossary term requires rework, the steward reworks and sends to the definition owner again for approval. If the glossary term is rejected, the steward ends the workflow after communicating to other users. The Requestor swimlane is added by default in the sample workflow diagrams for all facets. You can make use of the Requestor swimlane by creating additional tasks for the requestor or delete the swimlane if you do not want.
You can view the sample predefined workflow for the following facets:
- •Business Area
- •Capability
- •Glossary
- •Data Set
- •Client
- •Committee
- •Data Quality Rule
- •Policy
- •Process
- •Product
- •Project
- •Regulation
- •System
- •System Interface
Workflow Diagram Example
The example shows a new Default Workflow being created. Apart from the different start point, the functionality to build the workflow is identical. The facet used in this example is Product. After you select the Product facet, you can see that one default workflow already exists. You can either select this one to edit, or create another.
1. From the Axon toolbar, click Admin Panel under the user name.
The Admin Dashboard appears with the Axon version details, status of Axon services, and Axon message queues.
2. On the left navigation pane, click DG Operating Model > Default Workflows.
3. Select the Product facet for which you want to configure a workflow.
4. Choose to add a new workflow.
5. Enter a name for the workflow.
The name must contain a minimum of six characters.
6. Provide a description for the workflow.
Axon creates a canvas with many swimlanes based on the roles that are defined for the facet. Remember that the swimlanes appear with a lane for each type of stakeholder role configured for the facet, that is for the Product Steward, Product Owner role.
7. Click into one of the lanes, so that a dotted line appears, and use the bin icon on the menu to delete this lane. You can add it back in later if required.
8. From the toolbar, choose the Start Event, and place it in the Steward’s swimlane. This means that the objects stewards receive the first request to action when a ticket is raised against this request.
9. Typically the first thing that anyone does is to validate that the request should have been routed to this workflow. If OK, then do something. If Not OK, inform the requestor and close the ticket.
10. The first step is to raise a User Action, and populate the Properties on the right.
- a. Click into the Start action.
- b. From the options cloud that appears, choose the User Action and drop it in the Steward's swimlane.
A line automatically appears between the two concepts.
The following image shows the start step and the first user task of the workflow:
The User Action can be populated by completing the Properties section, as above.
11. Next, you need a Gateway to show that there are two options - accept as valid request or reject.
- a. Click in the User Action and the same option cloud appears as before. This time select the diamond shaped concept, ensuring that it is placed in the Steward's swimlane.
- b. In the next picture the user has increased the horizontal width of all swimlanes, increased the height of the Steward's swimlane, and finally used the lasso tool on the Toolbar to grab and move the concepts you have created so far to the bottom of the swimlane.
The following image shows the increased length of the swimlane:
12. Now, you can add the two possible paths. First, an invalid request needs a User Action to Inform the user and then a Close Action.
- a. Always remember to click the predecessor object, create the User Action, and close the workflow. Remember to populate the Properties for each object.
- b. Lines leaving a gateway MUST have a name added to them, because these will appear in the any active workflow as labels on the Accept/Reject buttons. Keep them short and clear.
The following image shows the workflow diagram with the user task:
13. If you want to leave the Gateway on the alternative (valid request) path, then you need to create the next User Task.
This step is to ‘Perform Detailed Analysis’, and has been created in the picture below. As you can see, this is also performed by the Product Steward.
The following image shows the workflow diagram with the user task:
14. After some additional tasks by the Steward shown as an additional User Task (Collate Report) in the same swimlane, it is time to send to the Product Owner user for review and approval.
This time, from the option cloud on the ‘Collate Report’ User Action, simply drag the User Action into the Owner’s swimlane, and fill in the Properties.
The following image shows the properties that you can fill in for the user task:
15. As the possible actions are to either accept or reject the findings in the report, you need a Gateway to show these two alternatives. If the Owner rejects the report, then you should connect this new Gateway to the User Action already created to ‘Advise Requestor of Action taken’, and then you close the workflow.
The following image shows the alternatives for the gateway:
16. As this Gateway and the User Action both already appear on the page, you need to do something slightly different to connect them.
- a. Click on the Gateway, and select the lines icon, from the option cloud.
- b. Once clicked simply move your mouse toward the ‘Advise Requestor…’ User Action, and a line will be drawn between them.
- c. Remember to go back to this new line and name it. Click in the line between the two concepts and fill in the Properties. The line’s name will later appear in the workflow step when the Owner has to accept/reject the step.
The following image shows the workflow with the Reject path complete:
17. If the reviewed report is accepted, add something in to show what happens. The Steward is expected to implement the report, so create a User Action in the Steward’s swimlane.
The following image shows the action added to the steward role:
18. Save and close the workflow.
you now have a completed workflow. All paths ultimately lead to the Close event. All lines leading FROM a Gateway have a name, which creates the approve/reject buttons in a live workflow.
19. When a Change Request is raised against the workflow, you can see the CR on the canvas.
You can see that:
- a. The Active Step, i.e. the step awaiting action is Green. If orange it is alerting users that the Due By Date is less than a day away.
- b. The description that was created for this workflow step (in the Properties section) appears as guidance on the action expected by the Steward in the Discussion section below the canvas..
- c. There are two green buttons in the Discussion, which allow the Steward to accept/reject the step. They have the same names as the lines that leave the Gateway immediately after the active User Action.
The following image shows the workflow diagram for the change request:
Configure Behavior of Change Requests
You can configure the behavior of change requests when users create or modify Axon objects.
You must have the Super Admin profile to perform this task.
1. From the Axon toolbar, click the Admin Panel menu item under your user name.
2. On the navigation pane, click Customize & Configure > System Settings.
3. In the Group list, select Change Requests.
4. Click Edit.
5. Select Auto-complete Change Requests if you want Axon to automatically complete change requests that have reached the end of the workflow.
6. Click Save.
7. In the Linux environment, run the following command to clear the Axon cache and restart the necessary services:
sh <INSTALLATION_DIR>/axonhome/third-party-app/scripts/paramsync
When you run the paramsync script, Axon restarts the HTTPD, Memcached, and email notification services.
Note: When you clear the cache and restart the Axon services, the Axon web interface might be disrupted for some users that are logged into Axon. Informatica recommends that you update the cache after you save your changes in all the System Settings pages. Additionally, perform this action during a maintenance period when very few users use Axon.
Configure Default Values for Automatic Change Requests
You can configure Axon to start a change request automatically whenever users create or modify an object.
You must have the Admin or Super Admin profile to perform this task.
When users create or modify an object, they can save the object without review from other stakeholders. In the Admin Panel, you can configure Axon to automatically start a change request and mandatorily use a workflow whenever users create or modify an object. This type of mandatory approval ensures that the right stakeholders have the opportunity to review the object changes that users make.
For more information on workflows and change requests, see the Workflows and Change Requests chapter in the Axon Data Governance 7.1 User Guide.
1. From the Axon toolbar, click the Admin Panel menu item under your user name.
2. In the menu on the left, under the DG Operating Model category, click Default Change Requests.
3. In the Facet list, select the facet for which you want to create a change request.
The option is available for the following facets:
- - Glossary
- - Data Set
- - System
4. Select the Enable Workflow Approval option to use the workflow that you want to define for the facet object.
The page displays the settings for the change request.
If you do not select this option, you can create or modify the facet objects without using the workflow.
5. Select the Enable Workflow for Facet Types option to configure different workflow for different object types.
For example, you can specify a workflow for change requests created for Glossary domain objects, and another workflow for change requests created for Glossary term objects.
The page displays the settings for the change request for different object types..
6. Configure the following properties for the change request for facet objects:
Property | Description |
---|
Default Change Request System | Default system that Axon must use for the change request. Select one of the following options: |
Default Workflow for Creating Object | Default workflow that Axon must use when you create an object. Select an active workflow that you have already created in Axon. To create or modify workflows, see Create a Default Workflow. Note: This field appears when you select Internal in the Default Change Request field. |
Default Workflow for Editing Object | Default workflow that Axon must use when you modify an existing object. Note: This field appears when you select Internal in the Default Change Request field. |
Additional Fields | Specify the additional fields that an external change request system requires to create a ticket. Enter the values in JSON format. When you specify the fields, the fields appear in the External Fields section of an Axon change request. For example, if the external system requires a change request to have a severity level and due date, you can configure Severity and Due Date as additional fields. Note: This field appears when you select ServiceNow in the Default Change Request field. |
Default Axon Status for Creating Object | Default value for the Axon Status field when you create an object. Note: If you create an object through the bulk upload operation, Axon ignores the value you enter in the bulk upload file for the Axon Status field and uses the value that you specify here. |
Default Lifecycle for Creating Object | Default value for the Lifecycle field when you create an object. Note: If you create an object through the bulk upload operation, make sure that in the bulk upload file you enter for the Lifecycle field the same value that you specify here. |
Default Change Request Type | Default value for the Type field when you create an object. |
Default Change Request Urgency | Default value for the Urgency field when you create an object. |
Default Change Request Severity | Default value for the Severity field when you create an object. |
7. In the Default Stakeholder Roles to be Used From Top-Level Object section, select the stakeholders that Axon must assign by default to the object that you want to create or modify.
The section displays the list of stakeholders that you have configured for the facet. To add or remove stakeholders, see
Configure Roles.
8. Configure the following properties for the change request for different object types:
Property | Description |
---|
Facet Type | Type of facet for which the change request and workflow setting is applicable. This option is available for the following facets: - - Glossary
- - Data Set
- - System
|
Default Change Request System | Default system that Axon must use for the change request. Select one of the following options: - - Internal. Use the Axon change request system.
Select Inherited from Facet option to use the workflow that Axon uses for change requests to the main facet object. - - ServiceNow. Use the ServiceNow change request system.
If the ServiceNow change request system is not configured for a particular facet type, the option will not appear in the dropdown list.
|
Default Workflow for Creating Object | Default workflow that Axon must use when you create an object of this facet type. You can change the default workflow configured for the specific object type. To create or modify workflows, see Create a Default Workflow. Note: For external change request system, default workflow for creating object is not applicable. |
Default Workflow for Editing Object | Default workflow that Axon must use when you modify an existing object of this facet type. Note: For external change request system, default workflow for creating object is not applicable. |
Default Change Request Type | Default value for the Type field when you create an object. Select Inherited from Facet option to use the workflow that Axon uses for change requests to the main facet object. |
9. You can click Restore Defaults to reset all the changes made to the properties for the change request for the different object types.
10. Click Save.
After you define a workflow for a change request and select the Enable Workflow Approval option, Axon uses the workflow when a user with the WebUser profile creates or modifies an object. For information on how to create Axon objects with a workflow, refer the Creating an Object topic in the Axon Data Governance 7.1 User Guide
Connect to External Change Request Systems
You can configure Axon to connect to external change request systems that you use in your organization. When you create or modify an object, Axon can create a ticket in the change request system and include the object stakeholders in the workflow. For example, if you create a new Policy object in Axon, the change request system can create a new ticket to track the inputs and approvals for the policy. When a Policy stakeholder participates in the workflow for Policy objects, the change request system tracks the object creation process and notifies the Policy stakeholder.
You must have the Admin or Super Admin profile to perform this task.
1. From the Axon toolbar, click the Admin Panel menu item under your user name.
2. In the menu on the left, under the DG Operating Model category, click Change Request Systems.
The page displays the change request systems that you have configured. If you configure Axon to connect to several instances of ServiceNow, the page displays all the instances.
3. Click on a change request system to configure its properties. Click Create to configure a new change request system for Axon to connect.
The page displays the properties of the change request system.
4. Configure the following properties:
Property | Description |
---|
Change Request System | Select the change request system that you want to configure. Axon supports connection to ServiceNow. |
Name | Name of the change request system instance. |
Server URL | URL of the change request system service in the following format: http(s)://<host_name> or http(s)://<IP_address> |
Server Login User Name | User name to log in to the change request system |
Server Login Password | Password to log in to the change request system |
External Status Field | Enter the field name in the change requests system that indicates the ticket status. For example, if the change request system uses the "State" field to indicate the ticket status, enter State here. |
Completed Status of Change Request | Enter the status in the External Status Field that corresponds to a completed change request. For example, if a completed status in the State field is indicated as "Resolved", enter Resolved. |
Cancelled Status of Change Request | Enter the status in the change request system that corresponds to a cancelled change request. For example, enter Cancelled or Revoked. |
Additional Fields | Optional. Specify the additional fields that the change request system requires to create a ticket. Enter the values in JSON format. When you specify the fields, the fields appear in the External Fields section of an Axon change request. For example, if the ticketing system requires a change request to have a severity level and due date, you can configure Severity and Due Date as additional fields. |
5. Click Save.
Note: When you clear the cache and restart the Axon services, the Axon web interface might be disrupted for some users that are logged into Axon. Informatica recommends that you update the cache after you save your changes in all the System Settings pages. Additionally, perform this action during a maintenance period when very few users are using Axon.
Configure Additional Fields for External Change Request System
When you configure Axon to connect to an external change request system, the external system might require additional fields that do not appear by default in the Axon configuration page. Enter the details of the additional fields in JSON format so that Axon can create change requests in the external system.
Go to the Axon Admin Panel, and navigate to DG Operating Model > Change Request Systems. Select an external change request system, and configure the additional fields in the Additional Fields field.
Format
Add each additional field in the following format:
{
"key": "<field_name_in_external_system>",
"displayName": "<field_display_name_in_Axon",
"dataType": "<list_or_text_box>",
"defaultValue": "<default_value>",
"isMandatory": <required_or_not>,
"isHidden": <display_in_Axon_or_not>,
"isSensitive": <mask_field_or_not>
}
Enter square brackets [ and ] at the beginning and end of your entry. Separate each parameter by a a comma ( , ), and separate each field configuration by a comma ( , ).
Parameter Descriptions
The following table explains the parameters that you can enter for each field:
Parameter | Description |
---|
key | Name of the field in the external change request system. For example, if the field in the external system is "Urgency", enter the following parameter and value: "key": "Urgency" |
displayName | Name of the field as you want it to appear on the Axon interface. For example, if you want the "Urgency" field in the external system to appear as Importance in Axon, enter the following parameter and value: "displayName": "Importance" |
dataType | Specify whether the field must appear in Axon as a dropdown list or a blank text box. - - To display the field in Axon as a dropdown list, enter the list value:
"dataType": "list" - - To display the field in Axon as a blank text box, leave the parameter as empty, or enter the null value:
"dataType": null
|
defaultValue | Default values that you want to display for the field. - - If you specify the field as a dropdown list in the dataType parameter, enter the dropdown values in a single line. Separate the values by a comma. For example, to specify the High, Medium, and Low values in the dropdown list, enter the following parameter and value:
"defaultValue": "High,Medium,Low" - - If you specify the field as a text box in the dataType parameter, enter the default text in the field. For example, to specify the "Accepted" default value in the text box, enter the following parameter and value:
"defaultValue": "Accepted"
|
isMandatory | Specify whether the field is required or optional. For required fields, Axon appends an asterisk ( ) to the field name. - - To mark the field as required, enter the true value:
"isMandatory": true - - To mark the field as optional, enter the false value:
"dataType": false
|
isHidden | Specify whether or not the field must appear in the Axon interface. - - If the field is essential to create a ticket, and you do not want to display the field in the Axon interface, enter the true value:
"isHidden": true - - If the field is essential to create a ticket, and you want to display the field in the Axon interface, enter the false value:
"isHidden": false
|
isSensitive | Specify whether you want to use asterisks to mask the values that the user enters in the field. For example, if the user enters an employee code, you might want to mask the entry. Note: To specify a field as sensitive, you must specify the field as a dropdown list in the dataType parameter. - - To mask the user inputs, enter the true value:
"isSensitive": true - - To not mask the user inputs, enter the false value:
"isSensitive": false
|
Example 1. Example
You want to display the following fields from the external change request system in Axon:
Parameter | Field 1 | Field 2 | Field 3 |
---|
"key" | The field in the external system is "Severity" | The field in the external system is "Description". | The field in the external system is "Category". |
"displayName" | You want to display the field as Importance in Axon. | You want to display the field as Description in Axon. | You want to display the field as Select the Issue Type in Axon. |
"dataType" | The field is a dropdown list. | The field is a text box. | The field is a dropdown list. |
"defaultValue" | The dropdown values of the list are High, Medium, and Low. | The default entry in the text box is "Enter an optional comment." | The dropdown values of the list are Hardware, Software, and Other. |
"isMandatory" | The field is mandatory. | The field is not mandatory. | The field is not mandatory. |
"isHidden" | The field is not hidden in the Axon interface. | The field is not hidden in the Axon interface. | The field is not hidden in the Axon interface. |
"isSensitive" | The field is not sensitive and does not need to be masked. | The field is not sensitive and does not need to be masked. | The field is not sensitive and does not need to be masked. |
To configure the fields, enter the following values in the Additional Fields field:
[
{
"key": "Severity",
"displayName": "Importance",
"dataType": "list",
"defaultValue": "High,Medium,Low",
"isMandatory": true,
"isHidden": false,
"isSensitive": false
},
{
"key": "Description",
"displayName": "Description",
"dataType": null,
"defaultValue": "Enter an optional comment.",
"isMandatory": false,
"isHidden": false,
"isSensitive": false
},
{
"key": "Category",
"displayName": "Select the Issue Type",
"dataType": "list",
"defaultValue": "Hardware,Software,Other",
"isMandatory": false,
"isHidden": false,
"isSensitive": false
}
]