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

BindingWhat 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