Access Controls
Access controls determine who can do what in your workspace. Roles define permission levels — viewer, editor, admin — and scopes determine whether those permissions apply to the entire workspace or specific projects. Properly configured access controls prevent unauthorized changes, protect sensitive prototypes, and simplify compliance reviews.
Why access controls protect team workflows
Without access controls, anyone with workspace access can edit any project. This is fine for small teams where everyone trusts each other, but it breaks down as teams grow. A new intern accidentally deleting a stakeholder demo prototype is a preventable incident if project-level permissions are configured.
Access controls also protect the review process. When only approved reviewers can change a prototype's status from "draft" to "approved," the approval workflow has integrity. Without controls, anyone can mark a prototype as approved, undermining the review process.
For regulated industries, access controls are a compliance requirement. Auditors need to verify that only authorized personnel can access prototypes containing sensitive data or pre-release product information.
Configuring access controls
- In workspace settings, review the default role assignments. New workspace members typically receive the "Editor" role. Adjust the default if your team prefers a more restrictive starting point like "Viewer."
- Create custom roles if the built-in options (Viewer, Editor, Admin) do not match your team structure. Common custom roles include "Reviewer" (can comment and approve but not edit) and "Library Maintainer" (can edit shared components but not individual projects).
- Assign roles at the workspace level for permissions that should apply everywhere. Most team members need a workspace-level role that gives them appropriate access across all projects.
- Override roles at the project level when specific projects need different access. A client prototype might restrict editing to the account team while giving the broader organization view-only access.
- Enable the audit log to record all access and permission changes. Review the log monthly to verify that access patterns match expectations and that former team members have been properly deprovisioned.
- Set up access reviews on a quarterly cadence. List all workspace members, their roles, and their last activity date. Remove inactive accounts and verify that role assignments still match current responsibilities.
Access control mistakes
- Giving everyone admin access to avoid permission-related support requests. Admin access allows destructive actions like workspace deletion and member removal that should be tightly controlled.
- Not revoking access when team members leave the organization. Stale accounts with active permissions are a security gap. Integrate access revocation with your offboarding process.
- Setting project-level permissions without communicating the rationale. When team members suddenly cannot access a project, they assume it is a bug rather than a policy. Explain permission changes proactively.
- Relying solely on workspace-level roles without project overrides. As the workspace grows, different projects need different access policies. Workspace-level roles are too coarse for complex team structures.
- Not testing permission changes before applying them broadly. Create a test project, assign the new roles, and verify that each role can and cannot do exactly what you intend before rolling changes out to real projects.
Tracking access control compliance
- Stale account count: The number of workspace members with no activity in the last ninety days. These accounts should be reviewed and either reactivated or removed.
- Over-privileged user count: The number of members with higher access than their role requires. Admin access should be limited to two or three people.
- Audit log review frequency: How often the access audit log is reviewed. Monthly reviews catch issues before they compound.
- Access change response time: How quickly permission requests are fulfilled or access is revoked after a role change. Fast response times indicate a well-managed access process.
When to tighten access controls
- When the workspace grows beyond ten active members and informal trust no longer scales.
- When prototypes start containing real user data, competitive intelligence, or pre-announcement product information that requires confidentiality.
- When a compliance audit identifies access control gaps that need remediation before the next review cycle.
- When a permission-related incident occurs, such as unauthorized edits to an approved prototype or accidental deletion of a shared project.
Key concepts
- Role: A predefined set of permissions that determines what actions a team member can perform in the workspace, such as viewer, editor, or admin.
- Permission scope: The boundary of what a role can access, from individual projects to the entire workspace.
- Audit log: A record of all access and permission changes in the workspace, used for compliance verification and security reviews.
FAQ
- Can I restrict access to specific projects? Yes. Project-level permissions let you control who can view, edit, or administer each project independently.
- How do I set up role-based access for large teams? Create custom roles that match your organization's structure, then assign team members to roles instead of managing individual permissions.
- Are access changes logged? Yes. Every permission change is recorded in the audit log with the timestamp, who made the change, and what was modified.
Next steps
Review your current role assignments against the principle of least privilege. Adjust any over-provisioned accounts this week and set up the audit log review cadence recommended above. Check the FAQ for edge cases specific to your team structure.