Skip to main content

Ownership Rules

On every object page in your aprity documentation, you'll see a section called Ownership Rules. It answers a question every Salesforce team eventually asks : "When a new record of this type is created, who ends up owning it ? And what happens on update ? On cascade from a parent record ?"

The Ownership Rules section flattens the owner-assignment logic scattered across triggers, flows, assignment rules, and automation into a single readable table per scenario.

What you'll see​

For each object that has any owner-assignment logic, the page contains one entry per trigger phase :

  • On creation -- who owns the record when it is first inserted.
  • On update -- who becomes the new owner when the record is updated under specific conditions.
  • On batch / on user action -- ownership changes triggered by batch jobs or explicit user actions.
  • Cascade from source record -- when the record's owner is inherited from a parent (e.g. an Opportunity inheriting from its Account).

For each rule, you'll see :

  • Target -- the destination owner. This can be :
    • A Queue (named, with the visible label and the underlying API name).
    • A specific User (named, with username and the user record id when known).
    • The current user (the running user at the moment of the assignment).
    • A cascade (the owner is taken from a related record -- you'll see which one).
    • Dynamic -- the owner is computed at runtime by Apex code. aprity documents the source method without exposing the raw computation.
  • Trigger conditions -- the values that must hold on the record for this rule to fire (record type, field values, status changes).
  • Source automation -- the trigger, flow, assignment rule, or approval process that performs the assignment, linked to its rule page.
  • Record type scope -- if the rule only applies to certain record types, they're listed.

When more than 40 ownership rules apply to a single object (very common on heavily-queued objects like Case or Lead), the section is split into a main page plus continuation parts so the table stays readable.

How rules are detected​

aprity does not invent ownership behaviour. The Ownership Rules section is the result of a deterministic scan of :

  • Every Apex assignment of OwnerId in triggers, services, and batch classes.
  • Every Flow element that sets the owner (record-triggered flows, screen flows, scheduled flows).
  • Every Salesforce Assignment Rule for Cases and Leads.
  • Every Workflow Field Update on OwnerId.
  • Approval Process owner reassignment steps.
  • Cascade rules inferred from sharing or trigger-driven parent-to-child reassignment.

For each detected assignment, aprity resolves the target (Queue / User / Profile / Record Type) by looking up the actual record in your org -- so the page shows the human-readable Queue name and Username, not just the technical 18-character id.

Plan availability​

Ownership Rules are documented on every plan where the relevant object is in the scan scope. There is no separate feature flag for this section -- it appears whenever there is owner-assignment logic to document.

Where to find them​

  • Object documentation pages : a dedicated Ownership Rules section on each object page that has any, in the web portal.
  • Customer Portal : the Ownership Rules anchor on each object page. See Customer Portal.
  • StorySite export : every ownership rule becomes one or more USER STORIES inside the relevant EPIC, with Given / When / Then acceptance criteria reflecting the trigger phase and conditions. See StorySite — Backlog export.
  • Help Agent / Story Agent : the agents are aware of ownership rules and will cite them when answering a question like "Who ends up owning a Case when …" or generating a story that touches ownership.

How to use them​

The Ownership Rules section is the right starting point when you need to :

  • Onboard a new admin -- understand how ownership flows across your top 5–10 objects before touching configuration.
  • Plan a queue redesign -- before changing a queue's membership, list every rule that assigns to that queue and confirm none breaks.
  • Audit compliance -- demonstrate that records of a given record type can only be owned by users with the right profile, or that high-value records always route through a specific user.
  • Diagnose a routing incident -- "Why did this Case land on User X instead of Queue Y ?" -- the Ownership Rules section ranks rules by trigger phase and conditions, so you can identify which one fired.
  • Plan a migration -- ownership logic often needs to be re-implemented in the target system. The flattened rule table is the spec.

Limitations​

  • Owner assignments computed at runtime by complex Apex logic (multi-hop lookups, formula-based queue selection) are documented as "dynamic" with a pointer to the source method. aprity does not execute your code to predict the runtime value.
  • When the same target Queue name is used in multiple regions or business units, aprity disambiguates by Developer Name. If your team relies on label-only identification, the table will show both fields side by side.
  • Approval-process owner reassignment is documented under the relevant approval process page, with a cross-link from the Ownership Rules section on the object page.

For anything else, contact support@aprity.ai.