Yes Buddy, there are definitely simpler ways to handle this, and your concern with Universal Request is very common.
Universal Request is really meant for complex, cross-department scenarios IT, HR, Facilities. In more IT-focused use cases, it often introduces extra records, duplicate data entry, and unnecessary handoffs, exactly what you’re describing.
Some simpler alternatives that work well:
Decide at intake and create only one record
Let the user submit a single form (portal or catalog item), then use logic to create either an Incident or a Request, not both. This keeps one ticket per issue and avoids duplication.
Incident-first approach
Everything starts as an Incident. If it turns out to be a request, convert it later or create a related RITM and close the Incident. This keeps intake simple and pushes the decision to the support team.
Catalog-only model (no UR)
Use the Service Catalog directly and create only RITMs. Even “break/fix” items can be modeled as catalog items with the right routing and SLAs.
Lightweight custom intake record
A small custom intake table that routes to Incident/Request/Change via Flow. Once routed, the intake record can auto-close. This gives you control without the overhead of Universal Request.
Basically, if UR is causing redundancy and confusion, it’s perfectly reasonable to not use it. Many teams do just fine with a single-record intake model and some smart routing logic.
@gramalingam - Please mark Accepted Solution and Thumbs Up if you found Helpful🙂
