Users submitting change requests

[KarsonD]

Hi, our out-of-the-box change management application seems to only have a read and write role. The Itil role also includes the write role. But I am looking for a user to be able to create change requests, have tasks assigned to them if needed, and to not be able to interact with change requests that they did not submit.

The roles I mentioned before do not accomplish this, seems like either too much access or too little. What is the best way handle users who live outside of IT that need to submit changes for business applications such as a core banking solution?

[Naveen20]

The recommended pattern is a combination of a restricted role + ACLs + a scoped catalog item or portal experience. Check these

1. Create a custom role (e.g. u_change_requester)

Rather than trying to make the OOB roles work, create a purpose-built role. You can make it contain sn_change_read so they inherit base visibility to the change form, but then layer restrictions on top. Alternatively, you can build it standalone without inheriting any change roles at all if you want full control.

2. Use Before Query Business Rules (record-level ACL) to restrict visibility

This is the key piece. A before-query business rule on change_request that appends a condition like requested_by=gs.getUserID() (or opened_by, depending on your process) ensures these users only ever see changes they submitted. This is more reliable than relying solely on ACL conditions for large-scale row filtering, though you can combine both approaches.

3. Control field-level access with ACLs

Create ACLs on change_request for create/write operations that grant access to your custom role, but scope the writable fields to only what a business requester should fill in — short description, description, justification, category, assignment group, planned dates, etc. Lock down fields like risk, CAB decision, and state transitions that should remain with the change management team.

4. Handle change tasks

For change tasks (change_task), you can use a similar before-query BR to restrict visibility to tasks where assigned_to is the current user OR the parent change's requested_by is the current user. This way they see tasks assigned to them on their own changes but nothing else.

5. Front it with a Record Producer or Catalog Item

Rather than giving these business users direct list/form access, create a Record Producer that generates the change request. This gives you full control over what fields they fill in, you can default values like type, category, and assignment group, and the portal experience feels much cleaner for non-IT users. If you're already using Service Portal, a custom widget or a scoped portal page works well too.

6. Consider the "Delegated" or "Standard Change" angle

If these business application changes follow repeatable patterns (e.g., core banking config changes), you might also look at Standard Change Templates or Standard Change Proposals. Users with minimal roles can submit pre-approved standard changes through the catalog, which drastically simplifies the approval and CAB process.