People & Permissions - Inkfire Frontdesk

Hierarchy ≠ permission

Someone can lead a department without becoming a platform administrator. Access should be assembled from role, department and explicit capabilities.

Management & access model

The visual hierarchy below is editable from the People & Roles section in WordPress.

Sonny ModeOwner/developer tier above ordinary platform administration. Every privileged action is auditable.

Permission intent

Platform architecture and developer controls
Module lifecycle
High-risk recovery approvals
Sensitive diagnostics
Cannot be silently inherited by another role

AdministratorOperational platform administration without unrestricted developer authority.

Permission intent

Users and ordinary configuration
Module operations within policy
Integrations excluding Sonny-only secrets
Operational reporting

ManagementCross-team oversight, reporting and approvals according to business responsibility.

Permission intent

Cross-department dashboards
Approvals
Capacity and service reporting
No automatic developer/system authority

Department ManagerOwns workflows, people and workload within a department.

Permission intent

Department work and reporting
Assignments
Approvals scoped to department
No unrelated department data by default

SpecialistExtra capabilities for a job function without promoting the person to administrator.

Permission intent

Explicit specialist abilities only
Examples: finance view, WebOps action, reporting

StaffStandard worker with only the modules and records required for their work.

Permission intent

My work
Assigned department tools
Record visibility based on capability and scope