Template Access vs. Submission Access | Role-Based vs. Template-Level Permissions
Overview
Xenia provides a flexible, multi-layered permission system that allows you to control both broad workspace access and granular template-specific permissions. Understanding the difference between these permission levels is essential for maintaining security, ensuring data privacy, and providing the right level of access to your team members.
This article covers:
- The difference between Template Access and Submission Access
- How Role-based Permissions differ from Individual Template-Level Permissions
- Best practices for implementing access controls
- Common use cases and examples
Template Access vs. Submission Access
Xenia separates access control into two distinct categories: Template Access and Submission Access. This separation ensures that you can control who can create forms and who can view the completed data independently.
Template Access
What It Controls: Template Access determines who can interact with the template blueprint itself—not the completed submissions.
Two Key Settings:
- Can Edit: Controls who can modify the template structure, add or remove questions, change workflows, and update template settings. This is essentially the "builder" permission.
- Can Submit: Controls who can fill out and submit the template. If a user's role is not listed here, they won't even see this template available on their device.
Important Rule: Anyone who can edit the template OR anyone who can submit the template will be able to see the template. If you're not listed in either category, the template will be completely hidden from your view.
| Permission | What It Means |
|---|---|
| Can Edit | Ability to modify the template structure, questions, workflows, and settings |
| Can Submit | Ability to fill out and submit the template as a form |
Submission Access
What It Controls: Submission Access determines who can view the completed data after someone submits a template. This is separate from Template Access because you may want different people to create forms versus view the results.
Three Visibility Levels:
- View Own: Users can only see submissions they personally completed
- View Own + Others at Location: Users can see their own submissions plus submissions completed by others at locations they have membership to
- View All: Users can see all submissions across the entire workspace, regardless of location
Additional Control: You can also control who can edit submission data after it has been submitted. This is particularly useful for HR or management roles that need to make corrections or updates to completed forms.
| Visibility Level | What Users Can See |
|---|---|
| View Own | Only submissions they personally completed |
| View Own + Others at Location | Their own submissions plus all submissions from users at their assigned locations |
| View All | All submissions across the entire workspace, regardless of location |
Privacy Controls
For sensitive templates, Xenia provides additional privacy options:
- Private on Mobile: Hides all submissions for this template on mobile devices, even if users have view permissions
- Restricted Submission Access: Carefully select only the roles that should see completed submissions, even if other roles can submit the form
Role-Based Permissions vs. Template-Level Permissions
Xenia uses a two-tiered permission system. Understanding how these layers work together is critical for proper access control.
Role-Based Permissions (Workspace-Wide)
Scope: Broad permissions that apply across the entire workspace and all modules
Role-based permissions are set in Settings > Roles and control general capabilities across the entire Xenia platform. These permissions affect what users can do across all templates, tasks, locations, and features.
Examples of Role-Based Permissions:
- Access Tasks: Determines if a user can see tasks at all
- View Task Scope: Controls whether users see only their own tasks, tasks at their location, or all tasks
- Change Task Status: Allows users to mark tasks as complete or change their status
- Access Operations Templates: Determines if users can access checklists and forms
- Manage Templates: Allows users to create, edit, delete, or archive templates
- Access Reporting: Determines if users can access the reporting module
Key Principle: If you give someone the ability to change task status via role-based permissions, they can change the status of any task they have visibility to. Role-based permissions are blanket settings that apply across the entire platform.
Template-Level Permissions (Granular Control)
Scope: Specific permissions that apply to individual templates only
Template-level permissions are set within each individual template's Settings > Access section. These permissions override and refine role-based permissions for that specific template.
Examples of Template-Level Permissions:
- Who can submit this template: Even if a role has "Access Operations Templates" permission, they won't see this template unless listed in "Can Submit"
- Who can view submissions: Controls exactly which roles can see completed data for this specific template
- Who can edit the template: Controls who can modify this specific template, separate from the general "Manage Templates" permission
How These Two Systems Work Together
Think of permissions as having two gates that both need to open:
| Action | Role-Based Permission | Template-Level Permission |
|---|---|---|
| Submit a form | "Access Operations Templates" must be enabled | Role must be listed in "Can Submit" |
| View submissions | "Access Operations Templates" must be enabled | Role must be listed in "Submission Access" with appropriate visibility level |
| Edit a template | "Manage Templates" must be enabled (OR user has Admin role with unrestricted access) | User or role must be listed in "Can Edit" |
The Admin Bypass
The Admin and Owner roles have a special permission called "Access all grants unrestricted access." This permission allows admins to bypass template-level restrictions, ensuring they can always access templates for troubleshooting and management purposes.
Important: Be very careful who receives the Admin role, as they can access and edit any template regardless of template-level permissions. You can also give this permission to any other Custom Role in your workspace.
Common Use Cases and Examples
Use Case 1: Sensitive HR Forms
Scenario: You have a Performance Notice template that should only be completed and viewed by HR and management, not regular store employees.
Solution:
- Template Access - Can Submit: Only HR Manager and Regional Manager roles
- Submission Access: HR Manager role can view all submissions; Regional Manager can view own + others at their locations
- Privacy Setting: Enable "Private on Mobile" to hide submissions from mobile devices
- Role-Based Permissions: Store Manager role does NOT have "Access Operations Templates" enabled for HR module
Use Case 2: Daily Store Checklists
Scenario: You have a Daily Store Walk checklist that all store employees should complete, but only managers should see the results.
Solution:
- Template Access - Can Submit: Store Employee, Store Manager, and Area Manager roles
- Submission Access: Store Employee role has "View Own"; Store Manager and Area Manager have "View Own + Others at Location"
- Role-Based Permissions: All roles have "Access Operations Templates" enabled
Use Case 3: Department-Specific Forms
Scenario: You have a Food Safety Checklist that should only be visible to food service employees, not to IT or facilities staff.
Solution:
- Template Access - Can Submit: Food Service Employee and Food Service Manager roles only
- Submission Access: Food Service Manager can view all; Food Service Employee can view own
- Role-Based Permissions: All operational roles have "Access Operations Templates", but IT Staff and Facilities roles are not listed in template-level permissions
Best Practices
- Start with broad role-based permissions, then restrict at the template level: It's easier to give general access and then limit specific templates than to constantly add permissions.
- Regularly audit template access: Review who has access to sensitive templates quarterly to ensure permissions remain appropriate.
- Use descriptive role names: Clear role names like "Store Manager" or "HR Manager" make it easier to assign template permissions correctly.
- Limit the "Manage Templates" permission: Only give this to users who need to create or modify templates, not to regular users.
- Test permissions with test users: Create test accounts with different roles to verify that access controls work as expected.
- Document your permission strategy: Keep a reference document that explains which roles should have access to which types of templates.
- Be careful with Admin role: The Admin role bypasses template-level restrictions, so only assign it to trusted users who need full system access.
Summary
Xenia's permission system provides both broad control through role-based permissions and granular control through template-level permissions. Template Access controls who can edit and submit templates, while Submission Access controls who can view completed data. Role-based permissions set workspace-wide capabilities, while template-level permissions allow you to fine-tune access for specific forms.
By understanding and properly configuring both layers of permissions, you can ensure that your team members have the right level of access—neither too much nor too little—while protecting sensitive information and maintaining operational efficiency.
Need Help?
If you have questions about configuring permissions in your Xenia workspace, please contact your Xenia Customer Success Manager or reach out to support@xenia.team
Comments
0 comments
Please sign in to leave a comment.