Org Structure

Requires. The Org Structure permission.

Org Structure lets you model your sales organization — regions, teams, and the reps in them — and then let a manager see the customers that were sold anywhere beneath them in that structure. A customer is tied to a unit automatically when they're sold, based on the rep who sold them, and stays with that unit even if the rep later moves.

Everything here runs through the one System — Sales tree. That is the only tree customers are attributed through, and because visibility is checked against a customer's attributed unit, it is also the only tree that grants anyone visibility. Extra trees you create are organizational reference only.

Two words do most of the work on these screens, and they mean different things:

	What it is
Tree	A whole structure, top to bottom. Your account has one to start with. A tree holds its own unit types and roles, and its own default visibility window.
Unit	One box inside a tree — a region, a team. Units nest under each other, people are members of units, and a customer is attributed to a unit.

You pick a tree first, then work with the units inside it.

This is separate from Organizational Hierarchy, which is the reports-to tree used for payroll.

What you set up

Org Structure has three building blocks. Trees are listed at Administration → Org Structure; unit types and roles belong to one tree, so you manage them from inside it — open a tree's Units, then use the Unit Types and Roles buttons:

Trees — a whole structure. The Type column tells you which is which:
- System — Sales is the tree SecurityTrax recognises in code. It is the only tree new sales are attributed through, and it can't be deleted. You can rename it; the rename is cosmetic and does not change which tree the system uses.
- Custom is any tree you add. Customers are never attributed through a custom tree, and a role in a custom tree grants no customer visibility — a manager placed in one sees no customers from it. Use custom trees to record a structure, not to control access. Naming a custom tree "Sales" does not make it the system Sales tree.
Unit types — the labels for the levels of a tree (for example Region, Team). Purely names; they don't change behavior, but they make reporting and the tree easier to read. Each tree has its own list.

Roles — what a member is on a unit, and how much they can see. Each tree has its own list. Only roles in the System — Sales tree affect what anyone can see. The name is yours; the visibility setting is what matters:

Visibility scope	The member can see customers sold in…
None	No units at all — not even their own. The default for a plain member.
Own unit only	Just the unit the membership is on.
Own unit and downline	That unit and everything below it.
Own unit and upline	That unit and everything above it.
Own unit, downline, and upline	Both directions from that unit.

A role can also set a depth — how many levels down (or up) to include. Leave it blank for no limit.

Heads up. Visibility comes from the role, not from being the rep on a customer. A person whose role scope is None sees no customers through Org Structure — even the ones they sold, and even ones in their own unit. Every account starts with two roles on the Sales tree: Manager (Own unit and downline) and Member (None).

The two things that decide what someone sees

They're independent, and a person has to pass both:

	Set by	Answers
Visibility scope	The role on their membership (or a per-person scope override)	Which units — none, own, downline, upline
Visibility window	The customer's unit, or the nearest unit above it that sets one, or the tree's fallback	How far back in time — how old a sale can be and still show

A customer shows up only when the person's scope reaches the customer's unit and the customer falls inside the window in force for that unit.

Visibility windows and "Inherit"

A window limits how far back a member can see. You set one on a unit, and you set a fallback on the tree. Every window is three parts: a mode (rolling days, current calendar year, or current and previous calendar year), the days if you picked rolling, and a based on date (sale, install, or funding).

Inherit on a unit means that unit sets no window. To find the window that actually applies to a customer, SecurityTrax starts at the unit the customer is attributed to and takes the first of these:

That unit's own window, if it sets one.
Otherwise, the window on the nearest unit above it that sets one — walking up the tree, and stopping at the first one found.
Otherwise, the tree's fallback window.
If none of those set a window, there is no age limit at all.

Heads up. The tree fallback is the last resort, not a blanket setting. A unit set to Inherit takes the nearest ancestor's window if any ancestor has one, and only reaches the tree fallback when no unit above it sets a window either.

A customer that has no date yet for the chosen basis — not funded, not installed — stays visible rather than being hidden.

Build the structure

Go to Administration → Org Structure and open a tree's Units.
Click Add Top-Level Unit to create a region, then use the + on any unit to add a child beneath it.
A brand-new tree starts with no unit types and no roles, and both are required — add a unit type before your first unit, and a role before your first member, using the buttons on the Structure page.
Use the move and delete controls on each row to reorganize. Deleting a unit that still has units under it prompts you to delete the whole branch.

Add members

Open a unit's members and click Add Member:

Field	Required?	What it does
User	Yes	The person joining this unit.
Role	Yes	Their role on the unit. This is what decides what they can see — a role scoped None shows them nothing.
Primary	No	Marks this as the unit that receives the user's new sales. A user can be primary on only one unit per tree; setting a new primary clears the old one — the form tells you which unit that is before you save.
Starts / Ends	No	Optional dates that bound the membership. They don't add or remove the person — the membership stays listed and still counts toward the unit's member total. Outside the dates the membership simply does nothing: no visibility, and new sales aren't attributed through it. Blank means no bound; the end date is inclusive.
Scope override	No	Overrides the role's visibility scope and depth for just this person, without changing the role. Use this instead of editing a shared role.
Transfer book of business	No	Only appears when Primary is checked on the Sales tree. Moves the customers still attributed to the user's previous primary unit into this one. Runs in the background, so the move finishes shortly after you save. Leave it unchecked to keep past sales with the unit they were sold into.

Note. "Primary" is what decides where a rep's future customers are attributed. A manager's role decides what they can see; a rep's primary membership decides where their sales land.

Changing a membership

Click the pencil on a member's row to edit it in place. Role, dates, scope override, and primary are all editable; the person is fixed, because swapping them would rewrite who a tenure belonged to — a different person is a new membership. Editing keeps the same record, so the tenure history stays intact. Removing and re-adding does not: the removal stamps an end date and the re-add starts a fresh record, which makes the history read as though the person left and rejoined.

Adding someone twice

Nothing stops you adding the same person to the same unit more than once, and that's deliberate — sequential tenures in one unit (say January to March, then June onward) are a legitimate record. The form tells you what already exists before you save:

If the person holds one or more memberships here that are still in effect, you get a warning listing each one by role, primary flag, and dates. All of those memberships apply at once, and removing one later will not end the person's access — the others still grant it. The remove confirmation repeats the warning, listing what would remain.
If the person's earlier memberships here have already ended, you get a neutral note listing them instead. Adding another starts a fresh tenure and leaves the earlier records intact.

Heads up. Clearing the old primary happens the moment you save, regardless of the Starts date. So if you pre-stage a rep's move by adding a primary that starts next month, they have no attribution unit between now and then, and anything they sell in that gap gets no org unit. To move a rep on a future date, add the membership on the day it takes effect.

Tip. Transfer book of business starts unchecked, which keeps a rep's past sales with the team that sold them. If your company reassigns the whole book every time someone changes teams, contact SecurityTrax support to have the box start checked instead. You can still change it on any individual membership.

Let a manager see their downline

Building the structure and adding a manager with an Own unit and downline role is only half of it. Downline visibility is enforced through a permission, so a manager also needs the Restriction - Only View If Customer Is In Org Unit Downline permission assigned in their permission group, for the locations their branch covers. Once that's in place, the manager's customer list and records automatically narrow to the customers sold under their part of the tree.

You can also filter any customer list by org unit: on the customer list, open the filters and pick one or more units under Org Unit to see just those branches.

Why can't a user see a customer?

Work down the list — the first mismatch is almost always the answer.

#	Check	How to confirm	Fix
1	*Their role's visibility scope is None.* By far the most common cause. A None scope grants no units at all, so the person sees nothing through Org Structure — including customers they personally sold and customers in their own unit.	Open the unit's members. Look at the Role column, then open Roles from that tree's Units page and check the role's Visibility Scope.	Move them to a role with the right scope, or set a Scope override on just their membership.
2	Being the sales rep doesn't grant visibility. The Only View If Customer Is In Org Unit Downline restriction only asks which unit the customer is attributed to — never who sold it.	Is the person's only customer restriction the org-unit one?	If they should see their own sales regardless of unit, also give them Only View If Marked As Sales Rep/Trainee/Trainer. Restrictions combine — matching any one of them is enough.
3	The customer isn't attributed to a unit. Attribution is stamped when the sale happens, from the rep's primary membership. Leads, customers with no rep, and sales made before the structure existed have no unit.	Check whether the customer shows an org unit. Filter the customer list by the expected unit and see if they appear.	Have the rep's primary membership in place before the sale. For back-catalog customers, ask SecurityTrax support about the attribution backfill.
4	Their membership is in a custom tree. Only the System — Sales tree grants visibility, so a role in any other tree gives them nothing — no matter how wide its scope.	Check the Type column on the trees list for the tree their membership is in.	Add their membership to the System — Sales tree instead.
5	The customer's unit is outside their scope. Their scope may reach the wrong direction, or depth may cut the branch off short.	Compare the customer's unit with the member's unit in the tree.	Widen the scope or clear the depth limit.
6	The sale falls outside the visibility window. An older sale drops out of view even when the scope is right.	Check the Visibility Window column on the customer's unit. If it reads Inherit, check each unit above it — the nearest one that sets a window wins — and only then the tree's fallback.	Lengthen or clear whichever window is actually in force.
7	The membership isn't active yet, or has ended. A membership outside its Starts / Ends dates grants nothing.	Check the Starts and Ends columns on the members list.	Clear or correct the dates.
8	They don't have customer access at that location. Org Structure narrows what someone can already see; it never widens it.	Check the user's permission group for customer View at the customer's location.	Grant customer access for that location.

Note. Restrictions are subtractive and combine with OR — a user sees a customer if any of their restrictions match. Adding a second restriction widens what they see; it never narrows it.

Organizational Hierarchy — the older reports-to tree used by payroll, which Org Structure supersedes. Only shown to companies already using it.
Permission Groups & Roles — where the downline-view restriction is assigned.