Decision Table Maintenance Delegation

[kchorny]

TLDR: We are harnessing the power of decision tables on a regular basis. However, we would like to delegate maintenance of the decision tables to the process owners who already have the itil role. Has anyone done this successfully? 

Long version:

We have a catalog item for requesting access to specific reports that live in another system.  The form allows a user to request access to multiple reports at once via a multi-row variable set. Each report requires approval from a different group, and the access request for each report is fulfilled by a different team. Therefore, we stored the data in a decision table (report name, fulfillment group, approval group) and use that to route approvals* and tasks. The process owner would like to be able to add or remove reports from the list without requiring intervention from admins/developers. The multi-row variable set 'select a report' variable is configured to dynamically pull the active options from the decision table and populate the variable choices, so all that's left is to give them limited access (can add a new row and update an existing row, but can't delete or modify inputs) to remove admins/developers from the process completely.  I understand this would require some custom ACLs, and am interested to hear if and how anyone may have tackled and conquered a similar situation.

This is not the only scenario where we'd like to delegate to process owners. As an alternative to the above, we are considering building a catalog item that allows a user to request an update to a selected decision table, provide the necessary data based on the decision table they need modified, and have the flow add or update the decision table rows appropriately. I would be interested in hearing if anyone has tackled this issue from that angle as well.

*The need for multiple approvals posed a whole new problem - the solution we came up with is out of scope of this question so I won't elaborate here, but it's kinda cool, if anyone is interested 🙂 )

[James Chun]

Hi @kchorny,

I have not implemented this but I strongly proposed the idea a few years ago for various reasons.

• Setting the clear responsibility - developers/admins should not be held responsible for incorrectly set approvals. The service owners should be the ones that maintain them. However, it's important to note that the developers must provide the functionality for the service owners to manage their own approval processes.
• Fast rollout/self-service - since there is no need to raise a request, nor a need to wait for the deployment, the change is applied in Production instantaneously
• Better employee experience for both parties (service owners and developers) - service owners no longer need to wait for the change and developers can spend their time on other 'more valuable' work

In regards to the 'role', I think you can grant one of the OOB roles but it may grant edit access to all decision tables - https://docs.servicenow.com/bundle/utah-application-development/page/administer/decision-table/refer...

Cheers