> For the complete documentation index, see [llms.txt](https://docs.alemba.com/asm-hermes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.alemba.com/asm-hermes/setup-and-configure-asm/configuring-your-system/configuration-post-go-live/asm-application-configuration-change-management/asm-application-configuration-change-screens.md). # ASM Application Configuration Change Screens {% hint style="warning" %} 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.** {% endhint %} You can follow along with this configuration in your own system if you would like a good starting point to enable CM for changes to the ASM System. {% hint style="info" %} **Audience:** System Administrators/ASM Developers with sufficient rights to update, change, and configure ASM, ASM Screens, and ASM Workflows. {% endhint %} ## Example For the sample Change Management (CM) workflow, you will need new Request, Approval, and Task Screens. You will also potentially need several new Message templates. See also: {% embed url="" %} {% embed url="" %} ## Request Screens **Request Screen Set -** ASM CHANGE REQUEST **The following Request Screens were created in the screen set:** * Request Details * Request Review {% hint style="info" %} You will notice we did not create a *Submission Screen*. That is because this particular workflow will not be submitted from the portal, rather it will exist only in Nano and Core. We did create a Portal review screen merely to cover the possibility of an analyst attempting to view the request details from the Portal. {% endhint %} In the Request Screen, we created and placed all of the fields for the data we need to capture (your own requirements may be sightly different). The new fields created were: 1. **ASM CHG Implementation Details** - Text Area (Used for Internal communications apart from Activity Log) 2. **ASM CHG Screens Impacted** - Text Field 3. **ASM CHG Workflow Template Affected** - Text Field 4. **ASM CHG Setting Impacted** / Other - Text Field 5. **ASM UAT Scheduled UAT Refresh DT** - Date/Time Field 6. **ASM Alemba Reference No** - Text Field 7. **ASM Change Review Team** - Multi-Select Person Lookup 8. **ASM CHG Developer** - Single-Select Analyst Lookup 9. **ASM Review Meeting DT** - Date Time Field 10. **ASM CHG Lead QA** - Single-Select Analyst Lookup 11. **ASM CHG QA Team** - Multi-Select Analyst Lookup 12. **ASM CHG Impacted Areas** - DD Multi-Select List (Used in rules-based Conditional branches) * Workflow * Screen(s) * CMDB * Person/Analyst * System Admin * Message(s) * RBAC (Role Based Access Security) * Self-Service Portal * Skins and Branding * Service Catalog * Integrations * Upgrade/Vendor 13. **ASM CHG RAG Status** - Single Select DD List * RED - Major Issues, Project slip likely * GREEN - On Track * YELLOW - Minor Issues See also: {% embed url="" %} Further, we relabeled several system fields, changed the color of the ticket's screen header and border, created links, and changed the some of the system field properties: 1. **User -** Relabeled *Project Champion/Stakeholder (This individual must be an "Analyst" in ASM).* A filter for "Analyst" was applied. 2. Deep Link the user's Manager and the user's Manager's Manager (as Director) 3. Relabeled the **Linked CI's** to *Impacted Applications and Assets - List all that will be directly impacted, and any that could potentially be impacted* 4. We added **Check\_1** and labeled it *Show Help - Display Process and Workflow Expected actions* 5. We added an HTML field and included text that outlines the implementation process and what the Analyst can expect to happen. It is hidden by a rule that evaluates whether or not Check\_1 is *on* or *off*. 6. We added **Y\_N\_1** and labeled it *Will this change impact Screens or Workflows?*
## Task Screens For this build, we created 3 specialized Task screens and [set the parent to the Request Screen set](https://docs.alemba.com/asm-hermes-10.6.8/setup-and-configure-asm/configuring-your-system/system-administration-settings/ipk-and-workflow/workflow-management/screen-sets-for-requests-tasks-and-approvals#creating); ### Analyst Default Task Screen ***System Administration>Workflow management>Task Screen Set*** **Screen Set Name -** ASM TASK CR **Parent Request Screen Set -** ASM CHANGE REQUEST **The following Task Screens were created in the screen set:** 1. Task Details 2. Schedule Meeting (Message Template)
### Analyst (Internal) Approval Task Screens ***System Administration>Workflow management>Approval Screen Set*** **Screen Set Name-** ASM APP CR **Parent Request Screen Set -** ASM CHANGE REQUEST **The following Task Screens were created in the screen set:** 1. Task Details (Uses default Approval screen) 2. ASM APP REVIEW (Message Template)
### User (External) Approval Task Screens {% hint style="info" %} This approval task is assigned to the Lead QA Analyst. They will merely be issuing a Pass/Fail at the end of testing. You could create a custom Approval screen that uses **Pass** for *Approve* and **Fail** for *Reject*, however for this build we left the defaults in place. {% endhint %} ***System Administration>Workflow management>User Approval Screen Set*** **Screen Set Name -** ASM USR APP CR **Parent Request Screen Set -** ASM CHANGE REQUEST **The following Task Screens were created in the screen set:** 1. Approval Review (Uses default User Approval screen) 2. ASM Change User Approval (Message Template)
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.alemba.com/asm-hermes/setup-and-configure-asm/configuring-your-system/configuration-post-go-live/asm-application-configuration-change-management/asm-application-configuration-change-screens.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.