Admin Attik permissions

Objective

• Deliver Attik Admin–level permission management as one coherent program: centralized updates across locations, templates (standard and brand-specific), and plain-language explanations for every permission.
• Lower support burden and access mistakes when people work across many brands and instances.
• Setting array that will live on user vs staff member.
• Need user templates that are editable at the admin level.

Background

• Operators currently face repeated per-location work and unclear semantics when permissions are fragmented or undocumented.
• The requirement is to treat this as a single program with clear steps, not isolated one-offs.
• Scope boundary: admin-level, cross-instance control—not the full instance-level permission UI; instance-specific expansion belongs with ATT-1121 when that is the right home.

Permissions Needed Now:

1. User Management
2. Action Flow Management
3. Client Care Dashabord
4. Can View
5. Can create new dashboard view
6. Can edit existing

Scope

Admin / product

• Attik Admin surfaces that today gate cross-company or internal admin actions; exact routes and modules live under attik-frontend/src/app/admin/ (for example client-care entry points and admin navigation in src/util/data/adminNavButtons.tsx).
• Permission and staff models on the API side will align with existing backend patterns for companies, users, and roles (search within attik-backend/src/routes/ and src/models/ for current auth and staff endpoints—Decision needed on which collections hold template definitions vs overrides).

Related

• Track adjacency to instance-level permission work via ATT-1121 as described in the preserved notes below.

References

• attik-frontend/src/app/admin/
• Related program boundary: ATT-1121 (see embed in original description)

Potential permission structure examples.

---

Original description

Users who run access across many locations want one coherent place to manage permissions: updating people without repeating the same work in every location, using templates (both standard and brand-specific) so setup is consistent, and having every permission explained in plain language so managers and trainers aren't guessing. This issue is the admin-level permissions program for Attik Admin: the cross-instance layer used to control access patterns across many brands and locations, not the instance-level permission surface itself. They are asking for this to be treated as a single program of work with clear steps, not a scatter of one-off fixes.

Why it matters: When access is fragmented or vague, support load goes up, mistakes slip through, and it's hard to trust that the same person has the right capabilities everywhere they work.

Scope boundary

• This issue covers admin-level permission management across instances: centralized user permission management, reusable templates, brand-level templates, and clear permission definitions.
• Instance-specific permission expansion should live under ATT-1121 or be linked there when the work is adjacent but still substantial.