Planning guideGet started › Set up your workspace

Planning Your Permissions Strategy

The most important thing about permissions isn't technical-it's organizational. If you don't understand who in your company needs access to what and why, no amount of technical configuration will create a permissions system that works. Permissions can be a complicated beast, but they can also be simple if you start by talking to your peers and understanding your organization first.

This guide will help you plan a permission structure that balances security with usability, starting with organizational understanding rather than technical configuration.

What You're Actually Solving For

Permissions are the invisible architecture that makes your digital asset management system secure, efficient, and frustration-free. Get them right, and users can access exactly what they need without confusion. Get them wrong, and you'll face constant requests for access, security concerns, and workflow bottlenecks.

The challenge? Most admins plan permissions in isolation-creating user groups and roles without first understanding the full picture of who needs access to what, and why. This leads to overly complex permission structures, too many administrators, and folder hierarchies that make consistent access control nearly impossible.

Key Takeaway: Permissions problems are usually organizational problems, not technical ones. Start with people, not settings.

The Three Mistakes Everyone Makes (And How to Avoid Them)

Before you start planning, learn from the most common permission mistakes. Recognizing these patterns will save you months of frustration.

Mistake #1: Creating Too Many Admins

One of the most common mistakes is granting admin access too liberally. Admins have full platform access, including the ability to change system settings, delete content permanently, modify user permissions, and alter metadata structures.

The problem: Too many admins means less accountability, higher security risk, and potential for accidental system changes that impact everyone.

What to do instead: Limit admin access to 2-3 people responsible for platform governance. Most power users (content managers, department leads) need contributor or manager permissions, not full admin access.

Quick Win: Right now, list who you think needs admin access. If it's more than 3 people, identify which ones actually need full admin versus elevated contributor permissions.

Mistake #2: Skipping Organizational Discovery

Admins often create user groups based on job titles or departments without understanding what those users actually need to access and do. This leads to constant permission adjustment requests.

The problem: Assumptions about access needs rarely match reality. You end up with either too restrictive permissions (constant access requests) or too permissive ones (security risks and content chaos).

What to do instead: Before creating groups, document specific access needs for each user type. What folders? What actions? What workflows? Get answers from department heads, content managers, and key stakeholders.

Quick Win: Schedule 30-minute conversations with 3-5 key department leads this week. Ask them: "What assets do your team members need to access daily?" and "What do they need to do with those assets?"

Mistake #3: Folder Structure and Permission Mismatch

Creating a folder structure without considering permission boundaries, or vice versa, leads to complex and confusing access control.

The problem: If your folder structure doesn't align with access boundaries, you'll need separate folder roles for parent folders and subfolders, and new folders can accidentally bypass your permission rules.

Example: You have a Marketing folder where most content is accessible to the marketing team, but nested within it is a Confidential subfolder that should only be accessible to senior management. Now you need complex overlapping rules that are hard to maintain.

What to do instead: Plan folders and permissions together as a unified system. Major permission boundaries should align with top-level or second-level folders, not deep within hierarchies.

Quick Win: Sketch your top-level folder structure on paper. Circle the folders that need different access rules. If most circles are on nested subfolders rather than top-level folders, your structure needs rethinking.

Step 1: Understanding Organizational Needs

This is the hardest part of permissions planning-not the technical setup, but getting alignment on who should access what. You cannot skip this step.

Here's the reality: departments aren't monolithic. Your Sales department might include global teams, regional teams, country-specific teams, account managers, sales operations, and sales enablement-each with vastly different needs for accessing and managing assets. A one-size-fits-all "Sales" user group won't work.

Questions to Answer First

Who are your user types?

Internal employees (which departments?)
Contractors or freelancers
External partners or agencies
Vendors or suppliers
Temporary or project-based users

What do different groups need to do?

View and download only?
Upload and contribute new content?
Edit metadata or manage versions?
Approve or review before publishing?
Delete or archive assets?
Share content externally?
Administer system settings?

What boundaries exist?

Departmental boundaries (HR assets vs. Marketing assets)
Client or project boundaries (Agency Client A vs. Client B)
Confidentiality levels (public, internal, restricted)
Geographic or regional divisions
Brand or product line divisions

What workflows require special permissions?

Approval processes (who approves what?)
Version control (who can check in/out?)
Asset lifecycle (who can archive vs. delete?)
Distribution and sharing (who can create public links?)

Within each department, what are the different user types? This is critical. Don't think "Marketing team" - think "Marketing contributors who upload campaign assets," "Marketing reviewers who approve content," "Marketing viewers who only download approved assets," and "Marketing managers who control brand guidelines."

Key Takeaway: This alignment work is the foundation of successful permissions planning. Do not start configuring permissions until you have clear answers to these questions.

Quick Win: Create a simple spreadsheet with four columns: Department, User Type Within Department, What They Need to Access, What They Need to Do. Fill in at least 10-15 rows based on conversations with stakeholders. This becomes your requirements document and will reveal the complexity you're actually dealing with.

Step 2: Understanding How Data Dwell Permissions Work

Now that you understand your organizational needs, you need to understand Data Dwell's permission architecture. The key is understanding the relationship between roles, user groups, and users.

The Permission Architecture

Roles are the foundation. A role is a collection of specific permissions-what actions can be performed, what records can be accessed, what features are visible. Roles are created and configured separately from user groups.

There are two types of roles:

Folder Roles - Control access to specific folders and the assets within them (view, upload, edit metadata, delete, share, etc.)
Application Roles - Control access to platform features, records, and administrative capabilities (manage portals, configure metadata, access reports, etc.)

User Groups are containers that combine multiple roles together. When you create a user group, you assign it one or more roles. The group inherits all permissions from all assigned roles.

Users are assigned to user groups. A user can be a member of multiple groups simultaneously. Their effective permissions are the accumulation of all permissions from all groups they belong to. If one group grants upload permission and another doesn't, the user can upload.

This many-to-many relationship is your strategic advantage. Because users can belong to multiple groups and inherit all their permissions, you can design a layered permission system where base permissions are shared and specialized permissions are added as needed.

What Permissions Control

Actions - Upload, download, edit metadata, delete, share, reprocess, version management
Record Access - View or manage different record types (Assets, Accounts, Portals, etc.)
Component Visibility - Access to specific features or components
Admin Features - Configuration of metadata, users, branding, reports, system settings
Distribution Capabilities - Portal creation and management for external sharing (primary method), or public link creation for direct asset sharing (technical use case controlled at folder level)

If a role doesn't define access to a specific action or feature, users won't see it in the interface.

Admin Groups

Groups can be designated as admin groups, which grants full platform access. Use this designation carefully-it's a powerful setting that bypasses all restrictions.

Think of Roles as Building Blocks

The most effective permission strategies treat roles as small, granular building blocks-like LEGO bricks-that can be combined in different ways rather than large, monolithic structures.

Example of granular thinking: Instead of creating one massive "Marketing Full Access" role, create smaller roles like:

A role that grants upload permissions
A role that grants metadata editing
A role that grants access to Marketing folders
A role that grants access to Shared Resources folders
A role that grants approval workflow permissions

These can then be combined differently in various user groups to create exactly the permission sets you need without duplicating role creation.

Key Takeaway: Roles define what's possible. User groups combine roles. Users inherit permissions from all their groups. This layered architecture gives you flexibility.

Quick Win: Open Data Dwell and review existing roles. List them out and note what permissions each one grants. Look for opportunities to create granular roles that can be combined rather than duplicating similar permissions across multiple large roles.

Step 3: The Critical Relationship Between Folders and Permissions

Your folder structure and permission strategy are deeply interconnected. This is one of the most common sources of permission problems.

Why Folder Structure Matters for Permissions

Folder roles grant access to specific folders and their contents. If your folder structure is overly complex or inconsistent, creating clean permission boundaries becomes nearly impossible.

Design Folders with Permissions in Mind

When planning your folder structure, consider:

Do major access boundaries align with top-level folders?
Are there subfolders that require different permissions than their parent?
Will contributors be able to understand where to upload based on their access?
Can you avoid nested folders with mixed permission requirements?

Best practice: Design your folder structure so that permission boundaries happen at top-level or second-level folders, not deep within hierarchies. This makes permission management much clearer.

Subfolder Permission Inheritance

When assigning folder roles to user groups, you can configure whether permissions apply to subfolders automatically or set customizable rules for specific subfolders.

Consider: Should Marketing team access to the Marketing folder automatically grant them access to all subfolders, or do some subfolders need different rules?

Plan this during folder structure design to avoid permission conflicts later.

The New Folder Problem

Here's a common scenario: You've set up permissions perfectly. Marketing has access to their folders, Sales to theirs. Then someone creates a new subfolder under Marketing, and suddenly the permissions don't work as expected-either too restrictive or too permissive.

This happens when folder creation permissions are too broad and subfolder inheritance isn't clearly defined.

Solutions:

Limit who can create folders (admins and content managers only)
Clearly define subfolder inheritance rules in your user groups
Document where new folders should be created and by whom
Regularly audit folder structure for rogue or incorrectly placed folders

Key Takeaway: Plan folders and permissions as one unified system. Changes to one affect the other.

Quick Win: Review your planned folder structure and highlight any folders where permissions should NOT inherit to subfolders. These are your danger zones that need special attention.

Step 4: Building Your Roles Strategy

Now you're ready to design your roles. Remember: roles are the building blocks of your permission system. The goal is to create granular, combinable roles that minimize duplication while maintaining flexibility.

Understanding the Two Role Types

Data Dwell has two fundamentally different role types that work in distinct ways:

Application Roles - System-wide permissions that apply everywhere:

These roles control access to platform features, administrative capabilities, and records
They apply across the entire system and cannot be restricted to specific folders
Examples: user management, metadata configuration, portal creation, report access
When you assign an Application Role to a user group, those permissions apply immediately and globally

Folder Roles - Permissions that CAN be scoped to specific folders:

These roles define what actions users can perform on: Assets, Folders, Asset Versions, and Public Links
The role itself doesn't specify which folders-it only defines what actions are possible
Examples of actions: view, download, upload, edit metadata, delete, share, version management
When you assign a Folder Role to a user group, you THEN select which specific folders that group can access using that role
The same Folder Role can be assigned to different user groups with different folder selections

Critical distinction: Application Roles are "set and done" - they apply system-wide. Folder Roles are "defined then scoped" - you create the role defining actions, then assign folders at the user group level.

Start by Identifying Common Permission Patterns

Review your organizational analysis from Step 1. Look for permission patterns that appear across multiple user types:

What capabilities do almost all users need? (Viewing assets, using search filters, downloading files)
What asset-related actions define major functional differences? (Upload vs. view-only, edit metadata vs. read-only, delete vs. archive-only)
What version control needs exist? (Who needs check-in/check-out capabilities?)
What sharing capabilities are needed? (Who can create public links?)
What administrative capabilities are needed system-wide? (User management, metadata configuration, reports)
What specialized workflows need unique permissions? (Approval workflows, portal creation)

Design Application Roles

Application Roles grant system-wide capabilities. Think about platform features and administrative functions:

Administrative Application Roles:

User Administrator - Create and manage user accounts and groups
Metadata Administrator - Configure metadata schemas and fields
System Administrator - Full platform configuration and settings

Feature Application Roles:

Portal Manager - Create and manage portals
Report Viewer - Access analytics and reporting
Workflow Manager - Configure and manage approval workflows

Keep Application Roles focused on platform-level capabilities that make sense to apply globally, not folder-specific actions.

Design Folder Roles

Folder Roles define what users can do with Assets, Folders, Asset Versions, and Public Links. Create roles based on functional patterns:

Basic Access Folder Roles:

Viewer - View and download assets, search and filter
Contributor - Everything in Viewer plus upload new assets and edit metadata on own uploads
Editor - Everything in Contributor plus edit any asset's metadata and manage versions
Manager - Everything in Editor plus delete assets and manage folder structure

Specialized Folder Roles:

Version Controller - Check-in/check-out capabilities for version management
Public Link Creator - Create public links for direct asset sharing (technical use case, not commonly used)
Approval Reviewer - View and approve assets in workflows (without edit access)
Read-Only Downloader - View and download only, no metadata visibility or upload

Remember: you're defining what actions are possible, not which folders these apply to. Folder assignment happens when you add these roles to user groups.

By keeping these roles separate and granular, you can combine them in user groups to create exactly the permission sets you need, then scope them to appropriate folders.

Balance Granularity with Practicality

As you create roles, look for natural groupings-capabilities that always work together:

Does everyone who can upload also need metadata editing? Maybe combine those into one Folder Role.
Does approval always require viewing and downloading? Keep those together.
Are there actions that are almost never used separately? Consider combining them to reduce complexity.

The goal is to minimize the total number of roles you need to create while maintaining the flexibility to support different user types.

Remember the workflow:

Create Application Roles for system-wide capabilities
Create Folder Roles for asset/folder/version/link actions
Assign roles to user groups (in Step 5)
For each Folder Role in a user group, select which folders that group can access
Add users to appropriate groups

Key Takeaway: Application Roles apply system-wide immediately. Folder Roles define actions, but folder assignment happens at the user group level. This separation gives you incredible flexibility.

Quick Win: Create two lists: (1) System-wide capabilities needed (these become Application Roles), and (2) Asset-related actions needed (these become Folder Roles). If you find yourself thinking "this role needs access to Marketing folder" during role creation, stop-that's not part of role design, that's part of user group configuration in Step 5.

Step 5: Designing Your User Groups

User groups are where roles come together to create complete permission sets for your actual users. This is where your organizational analysis and role strategy combine.

The Layered Approach

Because users can belong to multiple groups and accumulate permissions from all of them, the most efficient strategy is to use layers:

Layer 1: Default Employee Group

Create a baseline user group with the minimal common permissions every user needs. Assign ALL users to this group.

Assign a basic Folder Role (like "Viewer") and select Shared Resources or common folders everyone should access
Optionally assign Application Roles that everyone needs (like basic search/filter features if controlled by a role)

By putting these baseline permissions in a default group, you avoid having to assign them repeatedly in every other group. Every user gets them automatically.

Layer 2: Functional Groups

Create groups based on what users need to DO with assets:

Content Contributors - Assign a "Contributor" Folder Role, then select folders where these users should be able to upload and edit
Content Approvers - Assign an "Approval Reviewer" Folder Role plus any workflow-related Application Roles, then select folders where approvals happen
Portal Managers - Assign "Portal Manager" Application Role for creating and managing portals to share curated asset collections externally
Version Controllers - Assign a "Version Controller" Folder Role, then select folders where version management is needed

Layer 3: Access Boundary Groups

Create groups that grant access to specific folders or content areas using appropriate Folder Roles:

Marketing Access - Assign appropriate Folder Role(s), then select Marketing folders
Sales Access - Assign appropriate Folder Role(s), then select Sales folders
Client Project A Access - Assign appropriate Folder Role(s), then select specific client project folders
Confidential Content Access - Assign appropriate Folder Role(s), then select restricted/confidential folders

Layer 4: Administrative Groups

Create groups for platform administration using Application Roles:

Platform Administrators - Assign System Administrator Application Role (limit to 2-3 people)
User Administrators - Assign User Administrator Application Role only
Metadata Administrators - Assign Metadata Administrator Application Role only

How Layering Works in Practice

Let's say you have a Marketing team member named Sarah who needs to upload campaign assets to the Marketing folder and approve them before publishing:

Sarah is in "Default Employee" - has a basic Viewer role assigned to Shared Resources folders
Sarah is in "Content Contributors" - has a Contributor role assigned to Marketing folders (gives her upload and metadata editing in Marketing)
Sarah is in "Content Approvers" - has an Approval Reviewer role assigned to Marketing folders (adds approval permissions in Marketing)

Her effective permissions are the combination of all three groups. If later you need to give Sarah access to Sales folders too, you could either add her to an existing "Sales Access" group or create a new group with appropriate roles assigned to Sales folders.

Now consider Tom in Sales who only needs to view and download sales collateral:

Tom is in "Default Employee" - has a basic Viewer role assigned to Shared Resources folders
Tom is in "Sales Access" - has a Viewer role assigned to Sales folders

Tom needs only two group assignments because the roles assigned to those groups provide exactly what he needs.

Handling Complex Departmental Scenarios

Remember the global Sales department example? Here's how layering handles that complexity:

All sales team members are in "Default Employee" (basic viewer access to shared resources)
All sales team members are in "Sales Access" (viewer role assigned to Sales folders)
Regional sales managers are also in "Content Contributors" (contributor role assigned to Regional Materials folders for uploading)
Sales operations team is also in "Metadata Administrators" (application role for managing product catalogs system-wide)
Sales enablement team is also in "Portal Managers" (application role for creating portals to share curated asset collections with customers)
Global sales directors are also in "Content Approvers" (approval reviewer role assigned to all Sales folders for sign-off workflows)

You don't need five different "Sales" groups. You need smart layering where the same Folder Roles are assigned to different folders for different groups, reflecting what different people actually do and where they do it.

Keep It Manageable

Start with 8-12 user groups total:

1 Default Employee group
3-4 Functional groups (Contributors, Approvers, Sharers, etc.)
3-5 Access Boundary groups (department/project folders)
1-3 Administrative groups

Add more groups only when you have clear use cases that can't be solved by combining existing groups.

Key Takeaway: User groups should be designed for combination, not isolation. Think in layers, not silos.

Quick Win: Draft your layered group structure on paper right now. Draw four boxes (Default, Functional, Access Boundary, Admin) and list 2-3 potential groups in each. Pick 3 real user types from your organization and write out which groups they'd belong to. If you're assigning 5+ groups to most users, your groups might not be granular enough.

Document Your Group Logic

For each user group you create, document:

Group name and purpose
Which roles are assigned to this group
What folders this group has access to (if applicable)
What type of users should be assigned to this group
Which other groups users typically combine this with

This documentation is critical when onboarding new admins or responding to access requests.

Common Permission Scenarios

Here are real-world scenarios showing how to apply the layered permission strategy to solve specific organizational needs.

Content Creation and Contribution

Scenario: Marketing teams need to upload and tag assets for campaigns, while external contractors need restricted upload access to specific project folders without seeing the broader asset library.

Approach: Marketing employees are in Default Employee + Content Contributors group (with Contributor role assigned to Marketing folders). Contractors are in a separate External Contractors group that doesn't include default shared access-just a Contributor role assigned only to their specific project folders.

Brand Governance

Scenario: Brand managers require approval rights over assets before they go live, ensuring only approved, on-brand content gets distributed. Regional marketing teams need view and download access to approved assets but shouldn't modify master files.

Approach: Brand managers are in Default Employee + Content Contributors + Content Approvers groups (with Contributor and Approval Reviewer roles both assigned to Marketing folders). Regional teams are in Default Employee + Marketing Access (with only a Viewer role assigned to Marketing folders).

External Partners and Vendors

Scenario: Agencies, freelancers, or retail partners need access to specific asset collections or need to submit assets to you.

Approach: Use portals as your primary solution for external access-this avoids creating user accounts and eliminates permission complexity entirely. Portals provide a branded experience where external partners can view and download curated asset collections, and can even upload assets back to you via transfer links if needed. They don't need platform login credentials, reducing security risks and preventing access assignment mistakes. Only create full user accounts with an External Partners group (basic Viewer role assigned to specific project folders, not in Default Employee group) when external partners truly need direct platform access, which is rare. See Portal articles for more details on external sharing and transfer link configuration.

Asset Lifecycle Management

Scenario: Senior administrators need full control including deletion rights and system configuration, while most users should only be able to archive assets rather than permanently delete them.

Approach: Platform Administrators group has System Administrator Application Role plus Manager Folder Roles with full delete access. Regular Content Contributors have Contributor Folder Roles that include archive permissions (via metadata Status: Archived) but explicitly exclude delete permissions. Use filters to hide archived content from standard views.

Departmental Boundaries

Scenario: Sales teams need access to product images and sales collateral but shouldn't see HR-related assets or financial documents that other departments manage.

Approach: Create department-specific access groups (Sales Access, HR Access, Finance Access) where each group has appropriate Folder Roles assigned to their respective department folders. All users are in Default Employee for baseline capabilities, then added to appropriate access groups for folder boundaries.

Version Control and Review

Scenario: Designers need version management permissions to prevent simultaneous editing conflicts, while reviewers only need commenting capabilities without edit access.

Approach: Designers are in Default Employee + Content Contributors + Version Controllers groups (with Contributor and Version Controller roles assigned to Design Assets folders). Reviewers are in Default Employee + Content Approvers group (with Approval Reviewer role configured for comments only, assigned to Design Assets folders).

Quick Win: Identify which scenario most closely matches your primary use case. Map out the layered group assignments for 2-3 user types in that scenario. This helps you validate your group strategy before full implementation.

Implementation Strategy

Don't try to build the perfect permission system on day one. Use a phased approach that allows for learning and adjustment.

Phase 1: Create Roles First

Before creating user groups, build your role foundation:

Create granular capability roles (viewer, uploader, editor, approver)
Create folder access roles for major boundaries (departments, projects)
Create any necessary administrative roles
Test that roles grant the expected permissions

Phase 2: Start with Core Groups

Begin with a minimal set of user groups that cover your primary user types and access needs:

1 Default Employee group (with baseline roles)
2-3 Functional groups (Contributors, Approvers, etc.)
2-3 Access Boundary groups (department/project folders)
1-2 Admin groups

Launch with these core groups and gather feedback.

Phase 3: Observe and Adjust

After launch, monitor:

Access requests (what are people asking for?)
Permission conflicts (where are boundaries unclear?)
Workflow friction (what's slowing people down?)
Security concerns (any inappropriate access?)

Adjust groups and roles based on real usage, not assumptions.

Phase 4: Refine and Scale

As your organization grows or needs change:

Add new groups for emerging needs
Consolidate groups that are too similar
Review admin access regularly (do all admins still need full access?)
Audit folder structure and permissions quarterly

Warning: Don't plan for growth too far in advance. Design permission groups that can accommodate new users without constant reconfiguration, but don't over-engineer for hypothetical future scenarios. The layered approach handles growth naturally-you add users to existing group combinations rather than creating new groups.

Key Takeaway: Permissions are not set-and-forget. They evolve with your organization. Plan thoughtfully from the start, but build in flexibility to adapt as needs change.

Your Implementation Checklist

Map organizational access needs - Document who needs access to what across all departments, including different user types within each department
Align with stakeholders - Get department heads and content managers to agree on access boundaries and functional requirements
Review folder structure - Ensure folders and permission boundaries align clearly at top-level or second-level folders
Identify permission patterns - Look for common capabilities across user types and specialized needs that require unique permissions
Create granular roles - Build capability roles, folder access roles, and administrative roles that can be combined
Design layered user groups - Create Default Employee, Functional, Access Boundary, and Administrative groups
Limit admin access - Designate only 2-3 people as full platform administrators
Document group logic - Write clear documentation for each group explaining its purpose, assigned roles, and typical user combinations
Test with real users - Validate that permission combinations work as intended before full rollout
Plan for review - Schedule quarterly permission audits to adjust as organizational needs evolve