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.
Workflow Overview
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.
Workflow Task Details and Configuration
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.
TASK: ASM Stakeholder Application Change Review
Profile - CAB Approval
Description - Hello, a request to change ASM has been submitted. Please see the details of the change and if you approve, please complete the approval via email or by logging in to the Self-Service Portal. If you or any other stakeholder reject the change, a meeting will be convened to discuss the details and a second approval will be forwarded. If approval is not unanimous a second time after the meeting, the request will be cancelled and no further action will take place.
What happens next? Workflow Changes: If you approve of this change and the approval is unanimous;A task will be forwarded to the Lead developer to clone the workflow requiring a change and its associated screens. This new workflow will be placed into a secure development folder for completion by the assigned developer. A new Service action will also be created and assigned to the developers subscriber groups for the purpose of verifying and testing screens on the self service portal. This will hide the service action from view of the public while allowing the developers to verify rules, fields, and filters are working correctly.
All other Changes: If you approve the change and the approval is unanimous, a task will be forwarded to the developers group, the change will be implemented and tested, and then it will be released immediately.
Description - Hello, a request for change for ASM has been submitted and at least one approval authority has rejected the change. Please schedule a meeting with the Review board listed below. Once the meeting has been scheduled, enter the date and time in the meeting Date field on this task in ASM Core (You cannot complete this task via Email).
What Happens next? The meeting will convene and a single approval will be assigned to each member of the review board. Unanimous approval is required. If after the meeting we still do not have unanimous approval, this request will be considered rejected and it will close automatically. If we do achieve unanimous approval, the request for change will progress normally.
Thank you
Entity - ASM TSK CR
Phase - Initiation
APPROVAL: Second Chance ASM Change Request Review
Profile - Managerial Approval
Description - Hello, The Change requested for ASM was rejected initially by at least one of the member of the review board and so a meeting was scheduled. Once the meeting has been held and the change discussed by the team, please complete this approval and reject or approve it once again.
A unanimous approval is required for the request for change to the ASM application to proceed. Based on the results of the meeting that was held, please enter the decision.
Thank you
Entity - ASM APP CR
Phase - Initiation
USER APPROVAL: ASM Change QA Pass/Fail
Profile - User/Customer Approval
Description - Hello, Please complete UAT against this package. When testing is complete, please approve this task if it has passed, or reject it if it has failed. You will need to communicate the defects through your usual channels. Thank you
Entity - ASM USR APP CR
Phase - Testing
CONDITIONAL BRANCH: Does Change Impact Workflow or require new screens?
Profile - Unspecified
Description - NULL
Entity - Conditional Branching Task
Phase - Initiation
Conditions/Parent Actions/Dependent Tasks
WF YES/Activation Task/None/ASM Change: Set Up Developers Entities and Work Items
WF YES/Activation Task/None/ASM Change: Set Up Developers Entities and Work Items
{Request:ASM_IMPACTED AREAS} = "Workflow "
OR {Request:ASM_IMPACTED AREAS} = "Screen(s)"
OR {Request:ASM_IMPACTED AREAS} = "Self-Service Portal"
OR {Request:ASM_IMPACTED AREAS} = "Skins and Branding"
OR {Request:ASM_IMPACTED AREAS} = "Integrations"
OR {Request:ASM_IMPACTED AREAS} = "Upgrade/Vendor Project"
UAT NO - Rule Configuration -
NOT {Request:ASM_IMPACTED AREAS} = "Workflow "
OR NOT {Request:ASM_IMPACTED AREAS} = "Screen(s)"
OR NOT {Request:ASM_IMPACTED AREAS} = "Self-Service Portal"
OR NOT {Request:ASM_IMPACTED AREAS} = "Skins and Branding"
OR NOT {Request:ASM_IMPACTED AREAS} = "Integrations"
OR NOT {Request:ASM_IMPACTED AREAS} = "Upgrade/Vendor Project"
TASK: ASM Change: Set Up Developers Entities and Work Items
Profile - Implementation
Description - Hello, a change to ASM has been requested and approved. The change requestor/project champion has indicated that workflow and/or screens are impacted or that this is an entirely new workflow. This task is for you to configure entities necessary for the Lead Developer to begin work. Prerequisite: Ensure production has been configured for isolation and concealed development.
Summary List of Your Activities:
1. Workflow Template (New or Clone)
2. Screen Sets (New or Clone)
3. Request Assignment - Dev elopers
4. Task and Approval Assignment (Developers)
5. Subscriber Group Check
6. Service Action Setup - Subscriber Group
Note: If this request only involves screen changes, you may potentially skip over workflow items, if the changes will not impact the workflow. However, if the screens are used on a workflow or the changes impact workflow rules, you will need to follow all of the steps.
Example: Suppose the workflow for New User Onboarding is not changing but the screens that support the workflow are. The requirement is to add 2 new user types to a drop down list. You first check all of the rules in the workflow template and determine that at least 1 rule is in fact looking at this field. Now, you will need to follow the whole of the process because there is a conditional branch in the workflow that makes decisions based on the user type.
The workflow in this scenario will indeed, be changing. What seemed like a small change could actually have a bigger impact that the project champion may not know or understand.
Basic Detailed Process for establishing a development work order setup:
Ensure the developer is in the Developers subscriber group.
Clone the impacted workflow to the Development Workflow Process. See Also: Workflow Template Administration to learn more about creating new Workflow Templates
Create New Request Submission, Details, and Review Screen sets in System Administration. **You may also need to create approval and task screen setsUsing the current screens as a template, create the new screen entities.
Copy all Message Templates as well. Use the "Copy From".
Open the workflow you cloned, and point the request, all of the tasks, approvals and messages to the new screens and message templates. e.g., if the original screen task CR_TASK, the new Screen might well be called CR_TASKv2, and so on.
Assign all Tasks and Approvals to the 'Developers' Approval and Workflow Group.
Assign the request to the 'Developers' workflow group.
Save the request.
Access the CMDB and clone the impacted service action. This will be the one that calls the template you are modifying.
Point the cloned template to the new workflow you just cloned and rename the Service Action in such as a way as the developer will know which is in development. e.g., you could preface the Service Action Title with "DEV", or similar.
Before you click Save on the new service action, ensure you have added the subscriber group and unchecked the Available to all subscribers checkbox.
You have now created a dev template and screens along with a hidden service action. The developer can begin work without your users being able to see or being impacted by the developers activities.
What happens next? Now that you have configured the new version of the workflow, or perhaps created an entirely new one, a task will be created for the developer to begin work. You should include the name of the screens and template, Service Action etc, in you closing comments so that the developer assigned will know what entities have been configured.
Entity - ASM TSK CR
Phase - Build
TASK: ASM Change-Workflow Implementation/Update
Profile - SW Change-Implement
Description - Hello, A change to ASM Workflow and or Screens has been requested and approved. All of the necessary dev entities have been configured for you to begin work. Please the Request History" for any notes and information left for you by the individual who configured the environment. You will need to:Implement the Build/Change and perform a basic Unit Test.Document on the Request (Add a Note) any Risks, Actions, Issues, Decisions or Test Results. If the project is not on track or has issues, update the status to Yellow or Green as appropriate.When you have completed the work and you are ready to send it to UAT, you will complete this task. A new task will be created automatically and forwarded to the correct group or individual to log the Vendor ticket to have UAT refreshed with Production so that UAT may begin.
Please note: You are developing and completing this work in Production. No changes can be made in the UAT environment. Because of this you must:
Do not make changes in UAT as they cannot be moved backwards to Production.
Do not make changes to any entity apart from that which has been configured for you and approved through the Change Board already.
Entity - ASM TSK CR
Phase - Build
TASK: ASM Change Request Implementation
Profile - SW Change-Implement
Description - Hello, a change request for ASM has been approved and is ready for implementation. All of the necessary documents should be attached to the request. When the implementation is complete, include the details on this task and then please complete the task. Please hold this task open and keep a running narrative of any issues, actions or decisions until you have completed the build and unit testing. Do not complete this task until it is ready for either UAT or delivery. Include any results of your unit test where relevant.
Thank you
Entity - ASM TSK CR
Phase - Build
TASK: ASM Change-Copy PRD to UAT
Profile - Unit Test
Description - Hello, a request for a change to ASM has been submitted, approved and completed.
Please log a ticket at
https://alemba.help/production/portal.aspx to have the UAT environment refreshed with a copy of Production.
Enter the Request Number and the Date Time Requested. You cannot complete this task without this data.
What happens next? Once the UAT environment has been refreshed, UAT will commence. Once UAT has completed you will be required to enable this new capability in Production. We will not move any data from UAT to Production.
Entity - ASM TSK CR
Phase - Test
TASK: ASM Change-Test System Make Ready
Profile - Unit Test
Description - Hello, please make the UAT system ready for UAT testing. You may need to perform the following:
Ensure all email addresses are wiped, apart from the QA Team. This will ensure no emails go out to any unintended recipients.
Ensure all the task assignments in the workflow template are set to the correct groups for testing. Use your discretion how to handle this. When the workflow is ready to be published in Production, you will need to ensure the production tasks are correctly assigned.
Ensure that the service action for the project is not restricted by Subscriber group, else the QA team will not be able to see it.
This list is not inclusive, there may be other tasks you will need to perform on a case by case basis.
Entity - ASM TSK CR
Phase - Test
TASK: ASM Change UAT Passed: Make Ready/Publish PRD
Profile - SW Change-Completion
Description - Hello, an ASM Software change request has been completed and UAT has issued a PASS. Please make the change available in Production.
To publish the change (make the Change Visible):
In the Workflow Process Template Window, Highlight the Dev Workflow that is the subject of this call.
Click "Rename" and rename the Template appropriately.
Select the Workflow Process it should be located. e.g., DEV-Software Request v1 might get renamed to Software Request v1 and then be placed into the Service Request Fulfillment Workflow Process.
Open the workflow and in each task, email, and approval, set the assignments correctly. They will have all been set to the Developers Groups for development.
Click Assign on the Request and assign the workflow template to its default group.
If a dev Service Action was used, delete the DEV service Action.
If you updated a workflow template or created a new one, open the Published service action, and point the service action to the New workflow template.
Ensure the correct subscribers are listed or that if all users should see it that you have ticked the available to all subscribers.
Access the Portal where appropriate and ensure the final result is as expected
Access Core, and ensure the final result of the change is as expected.
Entity - ASM TSK CR
Phase - Change Implementation
CLOSE TASK: ASM Change Request Final Review and Closure Task (Manual Close Task)
Profile - Closure
Description - The ASM Change Request has been completed and Published. Please review the whole of the request and implementation and ensure it is complete. Then you may close the request in ASM using this task.
Thank you
Entity - Closure Task
Phase - Post Implementation Review
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.
