ASM Application Change Workflow Template
The ASM Change Workflow Template is constructed so that important steps along the way are followed.
Last updated
The ASM Change Workflow Template is constructed so that important steps along the way are followed.
Last updated
The ASM Application Configuration Change Management Workflow as detailed here, is provided as an example for those clients wishing to implement a targeted CM process around managing changes and configuration in their ASM application post go-live.
ASM ships with a standard Change Workflow for you to use that is widely applicable to all changes in your organization. ASM does not ship with the Change Management Workflow Template, message templates, or screens outlined in this section.
Audience: System Administrators/ASM Developers with sufficient rights to update, change, and configure ASM, ASM Screens, and ASM Workflows.
The ASM Change workflow will gather important change details, get stakeholder (ASM Change Review team) buy-in and send the change to UAT, if UAT is needed for the change.
Additional decisions and actions along the way:
If approval is not unanimous, a meeting will be scheduled with the stakeholders and change team to discuss. A second chance approval will then be issued and if unanimous, the change will progress to the next stage. If unanimous approval is still not received, the change will close.
The workflow will check if the change impacts screens or workflow and if so, will activate the UAT path. If not, it goes straight to implementation.
Once implementation is complete, an evaluation for the necessity of UAT is performed and if UAT conditions are met the UAT branch will be activated.
The UAT Branch will:
Create a task to copy Production down to the Test environment
Create a task to make the test environment ready for QA
Notify QA when UAT can start
If QA rejects the build, the workflow will activate a recursion back to the implementation task to try again.
Once QA passes the build, a task is created to enable the changes in Production.
Finally, the closure task is set to manual, assigned to the Release team, and when the release team has reviewed the whole of the request and results, they will close it.
Below are the critical tasks and their configuration. You will add or remove tasks from this list as necessary to meet your own organizational structure.
Activation Tasks - Are configured for unanimous approval. This means that if a single approver rejects, all remaining incomplete tasks will close and the meeting branch will be activated. If there is unanimous approval, then the request will instead, proceed.
Delay Task - The delay task is configured to wait to progress the request until the meeting date and time has elapsed for the Change Review and second chance approvals.
BEST PRACTICE - Always fill out the Task Description fully.
This is very often mapped as the body of the email notification for that task so at a minimum, you will want it to say enough to explain what the task is about and what the expected action is. It is also helpful to explain what happens next in the workflow on completion of this task. Click the image below to see an example
BEST PRACTICE - Always fill out all of the task information.
Pay particular attention to the "Request Status on Completion", "Request Status on Rejection" and the phase and status fields. Task Type is also important.
Request Status on Completion, etc... - By understanding what the status of the request should be when the current task is finished, you can have the workflow automatically update the request to reflect it. These status are tied to request phases. You can also make use of the request status to activate rules in the screens and in the workflows.
Task Types - These indicate the nature of the task, such as UAT, Unit Testing, Development, or Delivery. As above, you can then leverage this information to enforce field rules. For example, you might want to require a test result field but only on testing tasks and no others. If you are leveraging the task type, you need not write complex rules or create numerous screens.
Task Status/Phase - This indicates where the task sits in the big picture. This is very useful for reporting and filtering.
Order - this is a way for you to create a numerical system by which you can order the tasks in task lists. e.g., 100,200,300,310,311,320,400,500... By starting with big numbers I can now see from the example above that tasks 310 and 320 are clearly part of task 300's branch. 311 would be part of 310's branch, and so on. If you do not enter an order, then your tasks will appear in lists in random or alphabetical order and it can make following the workflow more difficult.
Task Priority - some tasks are more critical than others and by setting the correct priority, analysts are better able to see them in large lists.
Planned Time - The default planned time value is 168 hours, or 7 days. If your workflow has 10 tasks, the estimated completion date could easily be several months out. If you can enter the time the task should realistically take to complete, your auto-calculated dates will be much more accurate.
.
