Setting Up Roles, Teams, and Access Patterns

This article describes practical patterns for setting up member roles, teams, and Group access in StructureGram. It focuses on why you'd choose each pattern and which kinds of practice they suit — for the step-by-step how, see the linked articles in each section.

For the underlying mechanics of permission levels, defaults, and overrides, start with Understanding Access, Teams, and Sharing.

The One Decision That Drives Everything Else

Before assigning roles, decide one thing: what is your source of truth for client data?

• XPM is your source of truth. Most accounting and advisory practices using Xero Practice Manager fall here. XPM holds billing, compliance, and client identity. StructureGram is the diagramming and modelling layer on top.
• StructureGram is your source of truth. Some teams — particularly legal practices and estate planners — maintain entity and relationship data in StructureGram and use it as their primary record.
• They co-exist as peers. Both systems contain authoritative data and you actively reconcile between them.

This choice changes which roles are safe to grant freely and which are reserved for senior people. The patterns below assume the first case (XPM as source of truth) unless noted.

Pattern 1: XPM as Source of Truth — Free to Draft, Careful to Push

Use this when: XPM holds the canonical client data your team relies on, and you want StructureGram to be the place staff can model and diagram structures without risk of damaging XPM.

Setup:

• Senior advisers, partners, principals: Member - Group Admin. They can run reconciliations, push changes back to XPM, and delete from XPM when appropriate.
• Intermediate staff, paraplanners, advisers in training: Member - Edit. They can pull the latest XPM data, build diagrams, model restructure scenarios, and edit locally — but can't push back to XPM or delete from XPM. Mistakes stay in StructureGram and are easily recovered by pulling fresh.
• Support and administration staff who only need to look things up: Member - View.

Why this works:

• Junior and mid-level staff can use StructureGram daily without worrying about breaking XPM data.
• Push-back-to-XPM happens through a small number of senior people who can vouch for the change.
• Reconciliation becomes a deliberate, audited step rather than something accidentally triggered.

Practical refinement: if certain staff need to push for specific Groups (e.g. a senior paraplanner who handles all changes for one large client family), give them a member override of Group Manager on those specific Groups while leaving their baseline at Member - Edit.

See XPM Permissions by Member Role for the full XPM-specific permission breakdown.

Pattern 2: Small Firm, Everyone Works Across All Clients

Use this when: you have a small team (typically under 10 people), everyone touches most clients, and you want the simplest possible setup.

Setup:

• Invite everyone with a baseline that matches their day-to-day role: Member - Edit for advisers and most staff, Member - Group Admin for principals, Member - View for occasional users.
• Keep all Groups open by default (baseline access on).
• Skip Teams entirely — they add overhead you don't need at this scale.

Why this works: every new Group is immediately visible to everyone with the right role. No administration overhead per Group. Sensitive matters can still be handled by switching one Group to Restricted when you genuinely need to.

Watch out for: as the firm grows past ten or fifteen people, this pattern stops scaling — too many people see too many clients. Plan to move toward Pattern 3 before that happens.

Pattern 3: Growing or Mid-Sized Firm — Teams by Practice Area

Use this when: you have a team big enough that not everyone needs to see everything, but small enough that explicit Group-by-Group access would be exhausting to maintain.

Setup:

• Set baselines according to seniority, the same as Pattern 2.
• Create Teams that match how your work is organised — Corporate, Tax, Estate Planning, Commercial Litigation, Self-Managed Super, etc.
• Assign each Team to the Groups its members work on, choosing the right access level (Viewer / Editor / Group Manager) per Team.
• Members can still rely on their baseline access for Groups that aren't restricted; Teams give them stronger access on the Groups they specifically work on.

Why this works: new staff are slotted into a Team and automatically receive the right access across all of that Team's Groups. New Groups are assigned to a Team rather than configured per-user.

Practical refinement: if some matters require even tighter scoping than Teams provide, mark them as Restricted and grant access to specific individuals only.

See Team Management and How to Manage Members and Teams for the operational steps.

Pattern 4: Large Firm or Sensitive Practice — Closed by Default

Use this when: you have a larger organisation, sensitive client matters (estate planning, family law, mergers and acquisitions, contentious matters), or external compliance requirements that constrain who can see what.

Setup:

• Invite all members with Member - Granted Only. They see nothing until access is explicitly granted.
• Build Teams that match the access boundaries your work requires.
• Assign Teams to Groups deliberately. Every Group has an owner-team and members who belong to it; nothing is "visible to everyone" by default.
• Use individual member overrides only for one-off exceptions (someone covering for a colleague, an audit trail requirement).

Why this works: the default is zero access, so confidentiality is the assumed state. Anyone with access has been explicitly granted it. Easy to audit; easy to demonstrate to clients.

Trade-off: more administrative effort per Group. New Groups need a Team assignment before anyone can see them.

See Access Strategy and Permissions for a fuller treatment of open-by-default vs closed-by-default.

Pattern 5: Client or External Adviser Collaboration

Use this when: a client or external adviser needs to see or work on specific Groups, without being part of your organisation.

Setup:

• Invite the external person as a Guest via the Share button on the relevant Group.
• Choose Viewer if they should only read; choose Editor if they need to make changes (rare for guests).
• Guests can only see the Groups they've been explicitly shared into — they never see other clients.
• Periodically review tenancy-wide guest access from Account Settings → Sharing and remove guests who no longer need access.

Why this works: guests are isolated to specific Groups. They never inherit your organisation's baseline access; they never see your other clients.

See Guest Sharing and How to Share a Group with a Guest.

Decision Quick Reference

Common Mistakes to Avoid

• Giving everyone Tenancy Admin "for now". It looks simple at the start, but it removes every guard rail. Anyone can push to XPM, delete clients, change the organisation's settings, or manage other members. Use it for two or three principals at most.
• Skipping Teams when you have more than a few practice areas. If you find yourself configuring the same overrides on dozens of Groups, that's a sign you should have a Team doing it.
• Restricting Groups instead of using a member override. If only one person needs different access to a Group, an override is simpler than marking the whole Group restricted and granting access to everyone except them.
• Forgetting about Guests. Guest access is sticky — review it periodically. A client who finished an engagement two years ago might still be in your share list.

Related Topics

• Understanding Access, Teams, and Sharing
• Access Strategy and Permissions
• Access, Teams, and Sharing Overview
• Group Access and Permissions
• Team Management
• How to Manage Members and Teams
• How to Manage Group Access
• Guest Sharing
• How to Share a Group with a Guest
• XPM Permissions by Member Role