Disclaimer: The specific solution described is achieved through configuration. There is no liability for ServiceNow to provide support, apply changes, fix defects and review impact during future upgrades for the specific example that I provided in this article.
What problem does this solve?
Architectural Decision Records and Models from Enterprise Modeling and Visualization have an approval flow that is fixed on the Out-Of-The-Box "Enterprise Architecture Group". Customizing the approval flow is necessary for building dynamic approval processes that is common requirement when the EA solution starts scaling in an organization. While customizing the approval flow is straight forward, this article proposes a solution that makes the configuration of approvals dynamic, flexible but also easy to maintain with no-code/flow designer configurations.
The Solution
This is a demo of how the solution works for the EA Admin, Approvers & End Users:
Solution Details
What are artifacts and how approvals work on artifacts?
There is a great article that can be found here that explains how artifact, artifact versions and approvals are structured. We can summarize the following on how artifacts/approvals work:
Artifacts and artifact versions extend the document and document version tables and functionality from the core "Document Management" module of the platform (more on that here). Either it is a diagram/model or an Architectural Decision Record (ADR) - these are all stored under Architectural Artifact and Architectural Artifact Version tables.
Approvals are handled at the Version level. Whenever you trigger the action to "Submit for approval" an ADR or diagram/model, the approvals are created against the respective architectural artifact version record via a flow (named "Approve Architectural Architect Version"):
Visibility over the Artifact itself is governed at the artifact level (not the version) and is inheriting the functionality of Documents. By default, the creator/owner of the artifact has read/write access to the diagram. For Enterprise Architecture, there is an Out-Of-The-Box Business Rule (named "Reader permissions for EA") that creates "On Insert" of a new artifact a "Read" Group Permission record for the "Enterprise Architect Group". That's crucial so that the potential approvers in that group will be able to access and review the artifact before approving/rejecting:
All of these happen in the background while users use artifacts within the workspace.
What are artifacts and how approvals work on artifacts?
An update set is included with the customizations mentioned in this document that make up the "Artifact Configurable Approvals" proposed in this article. Use it at your own discretion and after testing accordingly on sub-production instances first before deploying it to any production environment.
The solution includes the following items exactly:
1. Introducing a new table for capturing the Approval Configurations. (As this is a custom table, please review your custom table entitlements before proceeding).
2. Modifying the OOTB "Approve Architectural Architect Version" to dynamically create approvals based on the Approval Configurations as well as creating "Group Permission" records for approvers to be able to access the artifact they're approving.
The update set ships the above custom elements in one package. You may review them in detail on Specifically:
1. A new table named "Artifact Approval Configuration" that holds the configuration records. Users with the sn_apm.apm_admin role can read/create/edit/delete those records and a module is added to access that (Enterprise Architecture -> Administration -> Artifact Approval Configurations).
2. A new Flow Designer Action named "Evaluate Artifact Approval Configurations" that is evaluating the Approval Configuration Records for a given artifact record and returns the relative approval group.
3. A customized version of the "Approve Architectural Architect Version" that uses the above-mentioned action to create the approvals for the appropriate group and for creating the Group Permission record.
4. A customized version of the "Ask EA for Approval" Email Notification (that is necessary because the OOTB notification is hard-coded to the default Enterprise Architecture Group as recipients).
As a reminder - this is a customization. Enterprise Architecture is a product that is constantly evolving. Although the approval flow might not be subject to change from ServiceNow in the next couple of months, this doesn't guarantee that it will not change in the more distant future based on an updated product roadmap. Weight the business justification of applying this solution versus the potential effort needed in the future to ensure no conflicts occur and if you choose to proceed with applying this solution, make sure you'll have a task to look at EA release notes and review skipped records whenever you update the Enterprise Architecture store plugins to a newer version.
