Get the parent request from an RITM

Every Requested Item belongs to exactly one Request, but that relationship can be null during record creation or in corrupted data scenarios. The current.request reference gives you direct access to the parent without additional database queries, but developers consistently forget the null check and crash their business rules when processing orphaned RITMs. The platform's dot-walking lets you access any field on the parent Request record, but you're still subject to ACLs and field-level security.

When to use this pattern

• Checking request approval state before processing RITM workflow transitions
• Copying request-level information (requested_for, justification, business_service) to RITM fields
• Validating RITM data against parent request constraints in Before business rules
• Building audit trails that include both RITM and request context

When NOT to use this

• In client scripts — use g_form.getReference() or GlideAjax for async access
• When processing hundreds of RITMs in a script — query sc_request once and join the data
• When you only need the request sys_id — use current.getValue('request') to avoid the reference query
• In display business rules that fire on list views — you'll create N+1 query performance problems

Key behaviors and gotchas

• Request states are integers: 1 (approved), -1 (rejected), 0 (pending approval) — string comparisons will fail
• Dot-walking respects ACLs — if the user can't read request fields, you get empty values not errors
• The request field is populated during RITM creation but can be null in Before Insert rules
• Domain separation applies — RITMs and their parent requests must be in accessible domains
• Use getDisplayValue() for reference fields like requested_for to get the user name not sys_id
• Request variables require separate queries through sc_item_option_mtom — they're not accessible via dot-walking