Team Hub Roles & Permissions 

This guide explains how roles, permissions, groups, and audiences work in Team Hub. It also covers common scenarios like creating a Content Creator role, migration notes, and best‑practice tips.

Definitions

• Role: A named collection of permission grants and denies; can be audience‑scoped, meaning the granted permissions can be limited to the visibility of a specific audience.
• Audience: A filter of users based on care setting, user group, and/or user type.
• Permission: The specific read/write capability for a feature area.
• Deny: Overrides any permission grant and removes access to the feature area if layered on top of another role with that feature area permitted.

• User Group: A subset of an audience container (e.g., Chess Club) used to scope a role’s effect in addition to care setting and user type - see Audience above.

• User Types: 6 user types are: Resident, Staff, Family, Vendor, Provider, and Contact (this list could expand in the future) - 3 of these are licensed users of our product and automatically get a base role of same name (i.e. Resident, Family, Staff)
• “Read” access: User can view the feature area, but not make or save changes
• “Write” access: User can view and make changes to the the feature area

 

How access is determined

Access = Base Role(s) + Custom Role(s) − Any Denies and is limited by any optional Audience restrictions a role might have

• Roles are collections of permissions and denies. Each user can have multiple roles layered together.
• Permissions come in three states per capability:
  
  • Do nothing: leaves the permission as default
  • Grant: explicitly allows an action/area
  • Deny: explicitly removes an action/area (overrides any grants of the same name)

 

Audience limits (optional): A role’s grants and denies can be limited to specific audiences (e.g., limit a creator to be able to publish content to the Chess Club audience only).

  

Base roles and onboarding

When users are onboarded via standard flows, they automatically receive a base role:

• Resident: for resident records (from EHR integrations)

• Staff: for staff records (from HR integrations)

• Vendor/Provider/Contact records default to no roles (no app access) until you explicitly assign one.

• Custom roles are layers on top of these base roles; do not remove the base role when customizing.

 

Working with roles in Team Hub

Compare permissions
When a role or multiple roles are selected, the permission sets for the roles are displayed in a table to the right for comparison allowing you to see side‑by‑side permission differences. This is helpful to answer questions like, “What can Activities Director do that Staff cannot?”

Create a custom role

1. Create Role by clicking the + button in the bottom right → name it (e.g., Content Creator).
2. Grant the needed permissions (e.g., Content Design Read/Write, Posts Create).
3. Optionally Deny any capabilities you want to ensure remain off (e.g., User Directory Read).
4. Optionally set Audience scope to limit where granted permissions apply (e.g., only within Chess Club).
5. Save.

Today there is no copy and paste role feature. Since custom roles act as overlays, we recommend building small, targeted roles that add needed grants or deny specific areas of a base role.

 

Assign a role to a user

• Open the user → Roles → Add Item → select the role → Save.
• To add additional Roles click Add Item again. Repeat as necessary

 

Permissions granularity and logical sets

• Permissions map closely to Team Hub areas and Fusion schemas (most areas have separate Read and Write toggles).
• Some capabilities are logically paired. 
  • Avoid permission mismatches. For example:
    
    • Designer Read/Write generally requires Pages and Elements permissions to avoid edit or save errors.
    • Dining Menus is most useful with Categories, Items, and Nutrition.

• The system does not auto‑enforce dependency selections; be thoughtful when checking boxes.

 

 

 Audience: scoping where a role applies

• An Audience is a Resident user group to whom you can target content (e.g., Chess Club).
• When you scope a role to an Audience, the user can exercise that role’s permissions only within that audience:
  
  • Example: A Content Creator scoped to Chess Club can create posts/events only for Chess Club—not the whole community.
    
    

 

Interactive display mode

This is just a suggestion of something that you may want to do and is in no way required. The goal here is to create a locked‑down user that displays content and allows browsing but denies the ability to sign up for events or perform edits.

1. Create role Interactive Display.
2. Grant needed Read permissions (e.g., event listings).
3. Deny interaction you want to block (e.g., Event Sign‑Up Read/Write, Service My Reade/Write).
4. Assign Interactive Display to a Resident user account that will be used on the device.

 

Integrations and auto‑assignment

• Today, vendors, prospects, and contacts enter without an assigned base role. 

 

Best practices & guardrails

• Prefer narrow, additive custom roles. Use Denies to remove edge capabilities from broad base roles.
• Scope to Audience whenever the audience should be limited.
• Name roles clearly (e.g., Resident Content Creator (Chess Club)).
• Pilot newly created custom roles with a few users, confirm behavior, then scale.

 

FAQ

Q: Can I clone an existing role (e.g., Staff) and tweak it?
A: No. Create a new role that customized grants and denies for the user’s existing role.

Q: A feature opens but errors on save. What’s wrong?
A: Likely missing a paired permission (e.g., Designer without Pages/Elements). Review logical sets.