Ownership and Visibility
Every Salesforce team eventually asks: "when a record of this type is created, who owns it? And who owns it after an update, a batch run, or a change on its parent record?" The answer is usually spread across triggers, flows, assignment rules and code.
On each object page that has owner-assignment logic, the Ownership and visibility section brings it together. It is part of the documentation on every plan.
Ownership scenarios
Rules are grouped by the moment they apply:
- Routing on creation
- Re-routing on update
- User action
- Inbound REST call
- Automated batch and Scheduled job
- Cascade from source record -- the owner is inherited from a related record.
Rules that apply only to some record types are grouped under those record types; the others under All records.
For each rule you see:
- If -- the conditions on the record (field values, record type, status change),
- Then -- the resulting owner,
- Source -- the automation that makes the assignment, with a link to its page,
- when several rules compete, their evaluation order as written in the source.
Kinds of target
| Target | Meaning |
|---|---|
| queue | A named queue, shown with its label and technical name. |
| user | A specific user. |
| current user action | The user performing the action. |
| cascade from source record | The owner of a related record. |
| dynamic target | The owner is computed at runtime by code. The calculation is described when it can be observed; otherwise the page says so. |
Targets driven by a custom setting are identified as such.
How ownership rules are found
aprity looks for every place that sets the record owner:
- owner assignments in Apex (triggers, services, batch classes),
- flows that set the owner,
- assignment rules for cases and leads,
- workflow field updates on the owner,
- cascades from a parent record.
For each target, aprity looks up the queue or user in your org so the page shows a readable name rather than a record ID. When the same place in the code assigns the owner several times in the same way, it is shown as one rule with the number of locations.
Where else ownership appears
- Migration backlog -- ownership rules feed user stories with acceptance criteria. See Migration Backlog.
- AI assistants -- the Org Expert can answer questions such as "who owns a case when ...?".
How to use it
- Onboarding an administrator before they touch routing.
- Redesigning queues -- list every rule that assigns to a queue before changing it.
- Diagnosing a routing incident -- find which rule applies to the record's situation.
- Migrating -- the scenarios are a specification of the routing logic to rebuild.
Limitations
- aprity does not run your code. When the owner is computed at runtime by complex logic, the rule is documented as a dynamic target, with the source and, when possible, the calculation.
- The section reflects the org at scan time.