Assign owners automatically with ownership rules

Ownership rules decide who owns each qualified account and contact, without anyone doing the handing out. You write the rules once - this filter goes to this team, that filter goes to those two reps - and every record that finishes qualification from then on lands with an owner, in the workspace and in your CRM.

This is the difference between a qualified list and a worked list. Qualification tells you an account is worth time; ownership is what makes it somebody’s time. Teams that skip this step end up with a growing pile of good accounts nobody has claimed, and a weekly meeting spent dividing them up by hand.

Ownership rules live in Settings, under Ownership rules. You need a seat whose team can view that area to open the page, and one that can manage it to create or change anything; a view-only seat sees the rules and the counts but no controls. See Teams, roles, and permissions.

Before you start

Records only become eligible once qualification has finished. An account needs an ICP verdict and a contact needs an IBP verdict before any rule can route it. Both Yes and No count as finished, so a rule can deliberately route the accounts you disqualified as well as the ones you kept. A record still waiting on its verdict is not skipped, it simply waits.
Decide how you want to treat records that already have an owner. Out of the box the rules only fill blanks: they assign owners to records that have none, and never touch a record already owned here or in your CRM. That is the safe default, and it is what most workspaces want on day one.
If you want owners to reach your CRM under the right name, map your people to their CRM seats first. Owner pushes resolve through the per-connection user mapping on the integration page, falling back to matching by email address. See Connect a CRM.
Know what your filters can express. A rule matches records with the same filter builder the Accounts and Contacts lists use, so anything you can build as a list you can build as a rule. See the accounts and contacts filter references.

Steps

1. Open the page and pick a side

Open Settings, then Ownership rules. The page has two tabs, Accounts and Contacts, each with its own set of rules. Start with Accounts: contacts can simply follow their account’s owner, which is how most teams want it and which needs no contact rules at all.

2. Add a rule

Click Add rule. The dialog is headed New account rule or New contact rule depending on the tab you are on.
Give it a Rule name that says who it routes to, not what it filters on (“EMEA enterprise accounts” reads better in a run history than “Rule 3”).
Under Records this rule matches, build the filter. This is the same builder as the lists, so you can combine verticals, ICP verdicts, scores, tags, custom fields, and CRM activity or pipeline conditions in one tree. Leave it empty only if you want the rule to catch everything that reaches it.
Under Assign to, pick people from the Users tab, teams from the Teams tab, or a mix of both. A team shows how many members it currently has.
Click Create rule.

Several assignees rotate round-robin, so a rule pointed at four reps splits its records evenly between them rather than dumping them on one. Teams are expanded to their members at the moment of assignment, which means a new teammate joins the rotation as soon as they join the team - you never edit the rule to add them.

3. Put the rules in the order you want them read

Rules run top to bottom, and the first one that matches a record wins. That is what lets you write a specific rule above a general one: “strategic accounts to the named-account team” first, “everything else in EMEA round-robin across the region” underneath.

Drag a rule by the grip at its left edge to change its position; the number beside the grip is its priority. Click the chevron to expand a rule and see the filter it matches on, its assignees, and who created it.

If a new rule overlaps one above it, a message tells you how many records the higher rule takes first. Nothing is blocked - it is a heads-up that the rule below will see fewer records than its filter suggests.

4. Switch the rule on

A new rule is created switched off. That is deliberate: you can build a whole rule set, put it in order, and check the preview before anything is assigned. When you are happy, use the switch on each rule to turn it on.

5. Check the preview before you turn everything on

The Preview card at the bottom of the tab is a live breakdown of where your records actually stand. For accounts it shows how many are Waiting on qualification, already Owned in Evergrowth, Owned in CRM, skipped, Locked, rules skip, and Matched by rules, then a per-rule list of how many records each rule would take, in priority order, ending with Matching no rule (stays unowned).

Read it as a sanity check on your rule set. A large “matching no rule” number means your rules do not cover your book; a large “owned in CRM, skipped” number means the override setting below is the thing standing between you and the assignment you expected. Use the refresh control to recount after an edit. On a very large book the per-rule counts are marked approximate, because a record matched by several rules is counted in each of them.

6. Decide how contacts get their owner

The Contacts tab leads with a single choice, Contacts follow their account’s owner:

On (the default) - every contact inherits the owner of its account, and contact rules do not run at all. This is the right answer for most teams: the account is the unit of ownership, and a contact belonging to somebody else’s account is a confusing artefact.
Off - contacts get owners from their own rules, which you then build exactly as you did for accounts. Turn this off when people at one company are genuinely worked by different reps, for instance when you split by persona or by product line rather than by company.

With inheritance on, a second switch appears: Move contacts when the account owner changes. Leave it on and contact owners follow later reassignments of the account, not just the first one, so a handed-over account arrives with its people attached.

7. Only if you mean it: let rules override existing owners

At the bottom of the page sits Override existing owners, collapsed, with an On or Off badge. Expand it to change it, and read what it says before you do:

Off - rules only assign owners to records that have none. A record with an owner here or in your CRM is never touched.
On - the rules become the sole authority on ownership. Records that already have an owner, including owners people set by hand and owners that came in from your CRM, are reassigned to match the rules, and the new owner is pushed to your CRM.

Turning it on asks you to confirm, because it applies to the whole workspace rather than to one list. Two things soften it: a record already owned by one of the matching rule’s assignees keeps its owner rather than being shuffled by rotation position, and every reassignment stores the owner it replaced.

If you want the rules to govern most of the book but not certain records, leave override on and lock the exceptions instead. A locked record is never assigned or reassigned by the rules, in either override mode. Lock and unlock from an account or contact’s detail page, from Other actions on a list selection, or as part of a bulk owner change. See Bulk-edit records.

What happens next

Assignment runs on its own every few minutes, so a record that finishes qualification gets its owner shortly afterwards rather than at the next nightly job. Each assignment is pushed to your connected CRM as the native record owner on the next sync.

A large backlog drains over several passes rather than all at once. That is intentional: every assignment is also a CRM write, and pacing them keeps a first switch-on from flooding your CRM.

Each rule keeps a Run history, reachable from the clock icon on its row. A run records how many records matched, how many were assigned, how many were kept because they were already owned by somebody in the rotation, and how the assignments split across people. A run is only written when something actually changed, so a settled rule showing no recent runs is working correctly, not stalled.

Two states are worth recognising on the rules list:

Needs attention replaces the on/off switch when none of a rule’s assignees are active any more - everybody named on it has left the workspace or been deactivated. Edit the assignees, then switch it back on.
A rule that keeps failing is switched off for you after several consecutive failed runs, so a broken rule cannot sit there silently doing nothing. Its run history says what went wrong.

You are notified when a rule is marked as needing attention, when one is switched off after repeated failures, and when somebody is dropped from a rotation because their CRM seat was deactivated. See Manage notifications.

Where an owner came from

Once a record has an owner, its detail page says how it got one: assigned by the ownership rules, set by an import, set by hand, set by Eva, or added through the Chrome extension. That line is what makes an unexpected owner diagnosable rather than mysterious - and it is the first thing to read before assuming a rule did something it did not.

Term mapping for Eva: the customer-facing name is “ownership rules”; a rule’s “assignees” are the people or teams it routes to; “kept” on a run means the record was already owned by somebody in that rule’s rotation and was left alone. The eligibility gate is a finished qualification verdict of any value, not a positive one - an account disqualified as not a fit is eligible for routing. The lock is a do-not-touch flag against this automation specifically and is unrelated to the qualification lock, which protects a verdict from being re-run; a customer who says “locked” may mean either, so ask which. Records matching no rule are deliberately left unowned rather than swept to a default owner, so “nobody owns these” is an expected outcome of a partial rule set, not a bug.