User & Team Access Management
Dynamic Access Starts with Users and Teams
Users and teams form the backbone of access control in the Kinetic Platform. Most security rules reference the current user's identity or team membership to determine what they can see or do.
This page focuses on how users and teams are used in access logic, not how they are created or managed.
👉 For administrative tasks like creating users or assigning team attributes, see Managing Users and Teams (Admin Guide).
Why It Matters
When writing security definitions or designing workflows, you’ll often rely on dynamic access logic such as:
identity('teams').includes('Department::HR')
hasIntersection(values('Assigned Team'), identity('teams'))
Instead of hardcoding usernames or roles, you can use teams and attributes to drive flexible, scalable access control.
Key Bindings
Binding | What it Returns |
---|---|
identity('username') | The logged-in user's username |
identity('teams') | A list of team slugs the user belongs to |
identity('attribute:Manager') | A user attribute value (e.g. Manager, email, or ID) |
These bindings are commonly used in security definitions for form access, submission visibility, and workflow decisions.
Structuring Teams for Access Control
To make the most of dynamic access logic, consider the following practicies:
- Mirror your org chart using parent/child teams.
Example: Department
is the parent. Department::HR
Department::IT
HR and IT are the child teams.
- Use team attributes to support routing and decision-making
Example: Attribute: Manager = [email protected]
- Use slugs consistently
Recommended Format: Function::Subgroup
. Keep naming predictable for use in expressions.
Real-World Examples:
Show a form only to HR:
identity('teams').includes('Department::HR')
Allow a user to view submissions assigned to their team:
hasIntersection(values('Assigned Team'), identity('teams'))
Allow routing to a team manager:
values('Manager Email') === identity('attribute:Manager')
Tips for Builders
- Use teams for role-based logic, not individual usernames
- Use attributes (e.g.,
Manager
,Location
) when you need specific routing targets - Use parent/child teams to manage access at multiple levels
- Keep your security definitions DRY (Don't Repeat Yourself) by reusing logic across forms
Related Topics
Updated 3 days ago