> For the complete documentation index, see [llms.txt](https://docs.rox.com/development/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rox.com/development/admin-guide/organization-settings/account-assignment.md). # Account Assignment How rules, filters, and organization defaults determine which CRM or warehouse accounts are assigned to each user in Rox. **Account Assignment** determines which accounts from your connected CRM or data warehouse are assigned to each user in Rox. Admins use rules to match accounts to users and filters to narrow those matches to the accounts each person should work on. A common use case is territory management: use the ownership and territory fields in your CRM or warehouse to assign each rep the accounts they should cover. For example, an account executive might receive accounts where they are the Account Owner, filtered to their assigned region. An SDR might receive accounts where they are listed in a custom SDR Owner field. Organization defaults provide a starting configuration, while personal rules and filters support users with different responsibilities. Account Assignment applies per user and requires the **Admin** role to configure. This page explains how assignments are evaluated, how defaults work, and what happens when assignments change. ### Assignment, sync, and visibility Your CRM or warehouse connection makes source data available to Rox. Account Assignment determines which accounts from these data sources are assigned to an individual user. It is not a filter on all data ingested by the organization’s integration. Other registration sources and Governance permissions can also affect what a user sees. For example, calendar activity can retain an account even when it no longer matches that user’s assignment rules. Removing an account from an assignment does not by itself establish that the user has lost every path to it. For managers and RevOps users who need team-wide or broader visibility, review the organization’s Governance configuration separately. A job title or admin role should not be treated as an automatic account-assignment rule. ### **How rules and filters work together** Each user's assignment has two components: | Component | Question it answers | Example | | ---------- | ---------------------------------------------------- | -------------------------------------------------------- | | **Rules** | Which accounts match this user? | Accounts where the user is Account Owner or SDR Owner | | **Filter** | Which of those matching accounts should be included? | Keep accounts with annual revenue of at least $1 million | Rox first determines the user's effective rules and filter, including any inherited defaults. It then combines the accounts matching any of those rules and applies the filter to that combined set. A filter does not add accounts that failed to match the rules. An account that matches a rule can still be excluded by the filter. #### Rules: match accounts to a user Rules are defined using fields on the Account object. Common rules use fields that reference a user, such as Salesforce's `ACCOUNT.OWNER_ID` or a custom SDR Owner field. A user can have multiple rules. These rules use **OR** logic: an account qualifies if it matches at least one of the user's effective rules. The account does not need to match every rule. For Enterprise customers, custom assignment logic can support more specific workflows. For example, an organization might assign accounts with an empty Outbound SDR Owner field to its inbound SDR team. Review custom logic with your Rox team during setup. #### Filters: narrow the matching accounts Filters use Account fields to restrict the accounts returned by the rules. Examples include keeping accounts in a particular segment or excluding accounts below a revenue threshold. Where field-based filter controls are available, Rox uses the field's data type to present relevant choices. For example, a picklist field offers its available values for selection. Source-specific setup may use a different configuration method. #### Example: two owner rules and a revenue filter Alex has two rules: **Account Owner is Alex** or **SDR Owner is Alex**. Alex's filter keeps accounts with annual revenue **greater than or equal to $1 million**. | Account | Account Owner | SDR Owner | Annual revenue | Result through these rules and filter | | ------- | ------------- | --------- | -------------- | --------------------------------------------------------------- | | Acme | Alex | Jordan | $5 million | Included: matches Account Owner and passes the filter | | Beacon | Jordan | Alex | $2 million | Included: matches SDR Owner and passes the filter | | Cedar | Alex | Alex | $750,000 | Excluded: matches both rules but fails the filter | | Delta | Jordan | Sam | $8 million | Excluded: passes the revenue condition but matches neither rule | | Elm | Alex | Jordan | $1 million | Included: the filter includes the threshold value | These results describe Account Assignment only. Other sources and permissions can also affect the accounts Alex sees in Rox. ### Organization defaults and personal settings Organization defaults let admins establish rules and a filter without configuring each user individually. Personal settings let an admin override either component for a particular user. > **Existing configurations:** The behavior below describes the newer assignment model. Organizations using a legacy configuration may resolve defaults differently. Confirm the applicable behavior with your Rox team before changing a legacy configuration. **Rules and filters inherit independently.** * Personal rules replace the organization default rules. They are not added to them. * A personal filter replaces the organization default filter (both filters are not applied together). * When a personal component is not set, the corresponding organization default applies, if configured. The first two columns show what an admin has configured for the user. The last column shows how Rox combines the selected rules and filter to determine the assignment. “Not set” means the user inherits that component from the organization default, if configured. | Personal rules configured? | Personal filter configured? | Resulting assignment | | -------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------- | | No | No | Accounts matching the **organization default rules**, narrowed by the **organization default filter** | | Yes | No | Accounts matching the **personal rules**, narrowed by the **organization default filter** | | No | Yes | Accounts matching the **organization default rules**, narrowed by the **personal filter** | | Yes | Yes | Accounts matching the **personal rules**, narrowed by the **personal filter** | For example, setting only a personal filter still uses the organization default rules. The account must match those rules **and** pass the personal filter. #### Example: change the owner rule and retain the default filter An organization's defaults are: * **Rule:** Account Owner matches the user. * **Filter:** Annual revenue is at least $1 million. Priya works as an SDR. An admin gives her a personal **SDR Owner** rule and leaves her personal filter unset. Priya receives accounts where she is the SDR Owner and annual revenue is at least $1 million. She inherits the revenue filter even though she has her own rule. The default Account Owner rule is replaced, so being an Account Owner alone does not qualify an account under this configuration. #### Example: replace the filter and retain the default rule Using the same defaults, an admin gives Mateo a personal filter for the **Healthcare** industry and leaves his personal rules unset. Mateo uses the default Account Owner rule with his Healthcare filter. The default revenue filter no longer applies. A Healthcare account he owns can therefore qualify even when its revenue is below $1 million. #### Clearing personal settings Clearing a personal rule restores use of the organization default rule, if one is configured. Clearing a personal filter restores the default filter. Leaving the personal filter unset therefore does not exempt the user from the organization’s filter. A personal filter replaces the default filter. If a user needs a broader set of accounts, configure an appropriate personal filter rather than assuming that clearing it disables filtering. #### Unconfigured, unmatched, and invalid rules Defaults apply when a personal rule is not configured. They are not a fallback for a configured rule that matches nothing or cannot be resolved. The following cases apply to the newer assignment model described above: | Configuration | Assignment behavior | | --------------------------------------------------- | -------------------------------------------------------------------------- | | No personal rule, default rule configured | Uses the default rule, with the independently resolved filter | | Neither personal nor default rule configured | Produces no accounts through Account Assignment | | Valid personal rule with no matching accounts | Produces no accounts through that rule (does not fall back to the default) | | Invalid configured relationship or filter reference | Produces a configuration error (does not substitute the default) | For example, a user with a personal SDR Owner rule does not receive accounts solely because they are the Account Owner. If the SDR Owner rule matches nothing, Rox does not switch to the default Account Owner rule. A zero-account assignment does not necessarily mean the user sees no accounts anywhere in Rox. Other registration sources and permissions may still apply. Similarly, a configuration error should not be treated as confirmation that previously accessible accounts have been removed. #### Before changing defaults A default change affects users who inherit that component. For example, changing the default filter can affect users with personal rules if they have no personal filter. Review each user's effective rules and filter separately. Having a personal rule does not mean the user is fully independent of organization defaults. ### When assignment changes take effect Account assignments are processed during graph builds and refreshes, when Rox updates its representation of connected records and their relationships. Assignment changes can also trigger asynchronous processing. Saving a configuration change does not mean the resulting assignments are immediately available. Changes take effect after processing completes. **Completion within 30 minutes is not guaranteed**. When an assignment depends on a CRM or warehouse value, that value also needs to be available in Rox for the assignment to reflect it. For example, after an Account Owner changes in Salesforce, Rox must receive the updated ownership data and process the assignment before the result reflects the new owner. #### Accounts that no longer match After processing, an account that no longer matches the effective rules and filter no longer qualifies through that assignment. It may remain registered to the user through another source, including eligible calendar activity. For example, changing an account's owner can remove the account from the previous owner's rule-based assignment. It may still remain available to that user if calendar activity independently qualifies it for retention. Removal from an assignment does not imply deletion of the underlying account or all of its associated data. If an account remains unexpectedly, review its other registration sources and Governance permissions with your Rox team. ### Related Contacts and Opportunities Account Assignment also determines which related Contacts and Opportunities are brought through assigned Accounts from the CRM or warehouse, subject to the objects and relationships supported by the integration. For this assignment path, the Account relationship is what matters. Contact or Opportunity ownership alone does not determine which related records are brought through. For example, an Account assigned to a rep can bring through a related Opportunity even when someone else owns that Opportunity. Owning an Opportunity alone does not establish assignment of its Account through these rules. Overall visibility can also depend on other account registration sources, Governance, and permissions. An assignment result should not be treated as a complete description of everything a user can access or change in Rox. ### Set up Account Assignment You need the **Admin** role in your Rox organization and a connected CRM or warehouse. Before configuring assignments, identify the Account fields that represent ownership or responsibility and the Account fields you will use to filter the results. Decide which settings should apply by default and which users need exceptions. Use the relevant setup guide: | Data source | Setup guide | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Salesforce | | | HubSpot or data warehouse | | For Salesforce, ongoing configuration is under **Settings → Integrations → Salesforce → Account Assignment**. HubSpot and warehouse configurations may use different screens, relationship definitions, or SQL-based filters. Follow the guide for your source, and work with your Rox team where custom relationships or warehouse views are required. ### Using Preview The Salesforce Account Assignment interface includes **Preview** to help inspect relationship matches. Preview may not include the effective account filter, so its count should not be treated as the final number of assigned accounts. Check the effective rules and filter, then verify the actual assignment after processing. Preview also does not establish all the accounts a user can access through other registration sources or Governance. ### Check representative users and accounts Review users with each combination of default and personal settings. Include at least one account that should match, one that should fail a rule, and one that should be excluded by a filter. For each case, check: 1. **Effective rules:** Is the user using personal rules or organization defaults? 2. **Effective filter:** Is the user using a personal filter or the default filter? 3. **Source values:** Do the Account's ownership and filter fields contain the expected values? 4. **Assignment result:** Does the account match at least one effective rule and pass the effective filter? 5. **Other sources and permissions:** Could another registration source or a permission affect what the user sees? After saving, allow processing to complete before comparing the user's account list with the expected result. ### Troubleshooting assignment results | What you observe | What to check | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | An expected account is missing | Check the user's effective rules, the source ownership values, the effective filter, and whether the latest data and assignment changes have been processed. | | A user with personal rules is unexpectedly missing accounts | Check whether they still inherit the organization default filter. | | A user receives accounts outside the default filter | Check whether a personal filter has replaced the default. | | An account matches one owner rule but not another | Multiple rules use **OR** logic. Matching one is sufficient, provided the effective filter also passes. | | An account remains after it stops matching | Check whether processing has completed and whether calendar registration, another source, or Governance provides a separate path to the account. | | A personal rule returns zero accounts | Confirm that the selected relationship is the one intended. A valid rule with no matches does not fall back to the organization default. | | Preview shows more accounts than expected | Check whether the count includes the effective filter. Compare against actual assignments after processing. | | A configuration error occurs | Check that the configured relationship and filter still exist and apply to the expected entity. Ask your Rox team to inspect unresolved references. | | A Contact or Opportunity does not appear as expected | Check the Account relationship, the user's Account assignment, the integration's object support and configuration, and applicable permissions. | If the result remains unclear, share a specific user, Account identifier, expected result, effective rules and filter, and the time of the change with your Rox team. Include whether the account was also added manually or registered through another source.