question How to design bidirectional relationships between RITM & Story/Demand/Project/Change (many-to-many?) in Community Central forum

How to design bidirectional relationships between RITM & Story/Demand/Project/Change (many-to-many?)

nawalkishos — Thu, 02 Apr 2026 10:22:26 GMT

Hi Experts,

I have requirement when the RITM is created, Then the RITM record should include the ability to associate it with one or more Stories, Demands, Projects, or Change Requests.

The reviewer should be able to do one of the following directly from the RITM record:

1 Create and relate a new Story
2 Create and relate a new Demand
3 Create and relate a new Project
4 Create and relate a new Change Request
5 Or relate the RITM to an existing record of any of those types

And if we open the Story, Demand, Project, change request- Then a related list labeled "Related RITMs" should display on the Story, Demand, Project, change request record showing all linked RITMs.

Please let me know to configure this and what will be the best approach in order to easy maintenance.

Thank you!!

Re: How to design bidirectional relationships between RITM & Story/Demand/Project/Change (many-t

AndersBGS — Thu, 02 Apr 2026 10:43:08 GMT

Hi @nawalkishos

Why - It is 2 completely different processes and methods according to ServiceNow. RITM = standard service requests requested by users, where story etc. Agile methodology and not standard defined.

What is the real business requirement here... Or is it because you have some teams working on RITMs and some teams working in an agile setup.

Re: How to design bidirectional relationships between RITM & Story/Demand/Project/Change (many-t

nawalkishos — Thu, 02 Apr 2026 10:53:41 GMT

I'm not sure the exact business needs here but that is the story that we need to configure, please share approach to handle this?

Re: How to design bidirectional relationships between RITM & Story/Demand/Project/Change (many-t

AndersBGS — Thu, 02 Apr 2026 11:06:06 GMT

Hi @nawalkishos

I would advise you to questioning it instead of "just doing".... This is not best practice. You off course need to come up with an alternative when questioning it, but to do that, you need to understand the business requirement.