Structuring Org Units and Territories Before You Add Assignment Rules
Assignment rules can route leads to a whole team, not just a person — but only if your org units are set up first. Here's how to structure them in CareSuite before you build routing on top.
It's tempting to jump straight to assignment rules — they're the visible payoff, the thing that actually routes leads for you. But assignment rules can target an org unit as easily as an individual person, and that option is only useful if your org units already reflect how your business is actually structured. This is the setup step worth doing first.
What an org unit is
An org unit in CareSuite (care_org_units) is a name and an optional parent_id — which is all it takes to model a hierarchy. A flat structure (a handful of top-level units, no nesting) works fine for a small team. A parent_id chain lets you go further: a regional structure with sub-teams underneath, or a department split into smaller working groups, without CareSuite forcing a fixed depth on you either way.
Membership is separate from the unit itself: care_org_unit_members links a user_id to an org_unit_id, and a person can belong to more than one unit if your structure calls for it — someone on both a regional sales team and a specialist product team, for instance.
This is also the largest single page in CareSuite's UI, which is a reasonable signal by itself: structuring org units is genuinely more involved than most of the app's other setup screens, because it's modeling something that varies enormously from one business to the next.
Designing the structure that fits your business
Before creating units, decide what axis actually matters for routing leads and assigning work in your business. For a lot of CareSuite's audience, that's geography — a set of territory-based units (North, Central, South, or city-level if you operate at that granularity) that a lead's location or source naturally maps to. For others it's product line, or a straightforward sales-team-versus-support-team split.
Resist the urge to mirror your full org chart if it doesn't correspond to how work actually gets routed. Org units in CareSuite exist to answer "who should this go to," not to reproduce a reporting-line diagram from HR — a unit with no routing purpose is just overhead in a dropdown menu six months from now.
Why this has to come before assignment rules
An assignment rule's target_org_unit_id field is only as useful as the units it can point to. Build assignment rules against an org structure that doesn't yet reflect your teams accurately, and you end up either routing everything to one catch-all unit (defeating the purpose) or constantly editing rules as you retroactively fix the underlying structure. Get the org units right first, and assignment rules become a much simpler configuration step layered cleanly on top — point a rule at a unit, and every current and future member of that unit is a valid recipient, without the rule itself needing to change as people move teams.
A practical starting order
Create your top-level units first — the broadest divisions that matter for routing (by territory, by product line, by function). Add members to each. Only then build out sub-units if a top-level unit is large enough that a further split changes how leads should actually be routed within it. This order — structure, then membership, then rules — keeps each step simple and avoids the rework that comes from building rules against a structure still in flux.