Team Patterns
Managing groups, roles, and hierarchies
Overview
Teams (or groups) are a fundamental pattern in LinkedRecords for managing access to shared resources. This guide covers how to create teams, manage membership, and implement role-based hierarchies.
Creating a Team
A team is simply an attribute with the appropriate permission facts:
Members vs Hosts
There are two levels of team participation:
Members ($isMemberOf)
Members can access resources shared with the team but cannot invite others:
Hosts ($isHostOf)
Hosts have all member permissions plus the ability to manage membership:
The team creator automatically has full permissions and can add members or hosts.
Invitation Flow
Only the team creator or a host can invite new members:
Self-Invitation Prevention
Users cannot add themselves to teams:
Revoking Membership
Removing Members
Hosts can remove members:
Members Leaving
Members can remove their own membership:
Removing Hosts
The creator can remove host status:
Removing host status also removes access to team resources (unless they're also a regular member).
Role Hierarchies
For more sophisticated access control, create multiple teams representing different roles:
Granting Role-Based Access
Organization Pattern
A complete organization structure with teams:
Listing Team Members
To get the list of members in a team:
getMembersOf() only works if you have appropriate access to the team.
Checking Authorization
To verify if you can see a team's membership:
Common Gotchas
1. Members Can't Invite
2. Verifying Fact Creation
3. Host vs Member Access
Being a host grants access through the team, but membership permissions are more explicit about what's allowed:
Best Practices
-
Create clear role hierarchies - Define distinct teams for different permission levels
-
Use hosts sparingly - Only give host permissions to users who need to manage team membership
-
Check fact creation results - Always verify that permission-related facts were created successfully
-
Document your permission model - Complex team hierarchies benefit from documentation
-
Consider accountability - Decide which entity (org or team) should be accountable for resources to manage quotas effectively
-
Test access patterns - Verify that users at each level have exactly the access they need