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.
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.
Before you start planning, learn from the most common permission mistakes. Recognizing these patterns will save you months of frustration.
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.
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?"
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.
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.
Who are your user types?
What do different groups need to do?
What boundaries exist?
What workflows require special permissions?
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.
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.
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:
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.
If a role doesn't define access to a specific action or feature, users won't see it in the interface.
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.
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:
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.
Your folder structure and permission strategy are deeply interconnected. This is one of the most common sources of permission problems.
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.
When planning your folder structure, consider:
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.
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.
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:
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.
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.
Data Dwell has two fundamentally different role types that work in distinct ways:
Application Roles - System-wide permissions that apply everywhere:
Folder Roles - Permissions that CAN be scoped to specific folders:
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.
Review your organizational analysis from Step 1. Look for permission patterns that appear across multiple user types:
Application Roles grant system-wide capabilities. Think about platform features and administrative functions:
Administrative Application Roles:
Feature Application Roles:
Keep Application Roles focused on platform-level capabilities that make sense to apply globally, not folder-specific actions.
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:
Specialized Folder Roles:
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.
As you create roles, look for natural groupings-capabilities that always work together:
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:
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.
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.
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.
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:
Layer 3: Access Boundary Groups
Create groups that grant access to specific folders or content areas using appropriate Folder Roles:
Layer 4: Administrative Groups
Create groups for platform administration using Application Roles:
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:
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 needs only two group assignments because the roles assigned to those groups provide exactly what he needs.
Remember the global Sales department example? Here's how layering handles that complexity:
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.
Start with 8-12 user groups total:
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.
For each user group you create, document:
This documentation is critical when onboarding new admins or responding to access requests.
Here are real-world scenarios showing how to apply the layered permission strategy to solve specific organizational needs.
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.
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).
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.
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.
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.
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.
Don't try to build the perfect permission system on day one. Use a phased approach that allows for learning and adjustment.
Before creating user groups, build your role foundation:
Begin with a minimal set of user groups that cover your primary user types and access needs:
Launch with these core groups and gather feedback.
After launch, monitor:
Adjust groups and roles based on real usage, not assumptions.
As your organization grows or needs change:
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.