Duda Roles and Permissions

Duda uses a role-based permission system that provides flexible control over team member capabilities. Understanding these roles is essential for secure team collaboration and client management.

How Duda Permissions Work

Role-Based Access Control

Duda implements a hierarchical permission system:

• Role: Predefined set of permissions (Admin, Designer, Developer, etc.)
• Site-Level Permissions: Granular access per site
• Account-Level Access: Organization-wide capabilities
• Client Access: Separate simplified permission system

Team Member → Role → Account Permissions + Site Access → Capabilities

Permission Hierarchy

Account Owner (Top Level)
├── Admin
├── Staff Manager
├── Designer
├── Developer
├── Site Contributor
└── Client (Separate Tier)

Team Member Roles

Account Owner

Purpose: Ultimate control over Duda account

Key Capabilities:

• Billing: Manage subscriptions and payments
• Account settings: Configure account-level settings
• Team management: Add, remove, modify all team members
• All sites: Full access to all sites
• White label: Configure branding (if applicable)
• API access: Generate and manage API credentials
• Transfer ownership: Can transfer to another user

Unique Permissions:

✓ Delete account
✓ Change plan/billing
✓ Transfer account ownership
✓ Configure white label settings
✓ Generate API credentials
✓ Access all features and settings
✓ Cannot be removed (only transferred)

Use Cases:

• Business owner
• Agency principal
• Primary stakeholder

Limitations:

• Only one owner per account
• Cannot be removed, only transferred
• Responsible for billing

Admin

Purpose: Full operational control without billing access

Key Capabilities:

• Team management: Add, edit, remove team members (except owner)
• All sites: Full access to all sites
• Site creation: Create unlimited sites
• Settings: Configure most account settings
• Templates: Manage site templates
• Integrations: Configure third-party integrations
• Cannot: Access billing, change plan, delete account

Permission Breakdown:

Sites:
├── View: ✓ (all sites)
├── Create: ✓
├── Edit: ✓
├── Publish: ✓
├── Delete: ✓
└── Transfer: ✓

Team:
├── View: ✓
├── Add: ✓
├── Edit: ✓ (except owner)
├── Remove: ✓ (except owner)
└── Manage roles: ✓

Settings:
├── Account: ✓ (most settings)
├── Billing: ✗
├── API: ✓ (view only)
├── White Label: ✓
└── Integrations: ✓

Content:
├── Templates: ✓ (manage)
├── Assets: ✓ (full access)
├── Custom Code: ✓
└── App Store: ✓

Use Cases:

• Operations manager
• Lead designer
• Agency account manager
• Technical director

Best For:

• Users needing full operational control
• Trusted senior team members
• Multi-site managers

Staff Manager

Purpose: Manage team members and their permissions

Key Capabilities:

• Team management: Add, edit, remove team members
• Permission assignment: Assign roles and site access
• Site access: Access to assigned sites only
• Cannot: Access all sites, change account settings, manage billing

Permission Breakdown:

Sites:
├── View: ✓ (assigned only)
├── Create: ✓
├── Edit: ✓ (assigned only)
├── Publish: ✓ (assigned only)
├── Delete: ✓ (assigned only)
└── Transfer: ✗

Team:
├── View: ✓
├── Add: ✓
├── Edit: ✓
├── Remove: ✓
└── Manage roles: ✓

Settings:
├── Account: ✗
├── Team: ✓
├── Notifications: ✓
└── Site-specific: ✓

Use Cases:

• HR manager
• Team lead with HR duties
• Mid-level manager
• Department head

Differences from Admin:

• No access to all sites automatically
• Can't change account-level settings
• Site access must be explicitly granted

Designer

Purpose: Create and edit websites

Key Capabilities:

• Site editing: Full editing capabilities
• Publishing: Publish sites to live
• Content management: Add/edit all content
• Design: Modify design and layout
• Widgets: Add and configure widgets
• Cannot: Manage team, access account settings, custom code

Permission Breakdown:

Sites (Assigned):
├── View: ✓
├── Create: ✓
├── Edit: ✓ (full design)
├── Publish: ✓
├── Delete: ✗ (site-level setting)
└── Duplicate: ✓

Content:
├── Pages: ✓ (full CRUD)
├── Blog: ✓
├── Products: ✓
├── Media: ✓
└── Forms: ✓

Design:
├── Layouts: ✓
├── Styles: ✓
├── Widgets: ✓
├── Animations: ✓
└── Responsive: ✓

Advanced:
├── Custom Code: ✗
├── Code Editor: ✗
├── Site Settings: Limited
└── SEO: ✓

Team:
├── View: ✗
├── Manage: ✗

Use Cases:

• Web designers
• Content creators
• Freelance designers
• Junior developers

Ideal For:

• Users focused on visual design
• Content-heavy site management
• Client-facing site updates

Developer

Purpose: Technical site development and customization

Key Capabilities:

• All Designer permissions: Plus advanced features
• Custom code: HTML, CSS, JavaScript editing
• Code editor: Full code access
• Advanced widgets: Custom widget development
• Site settings: Technical configurations
• API: Site-level API access
• Cannot: Manage team, access billing

Permission Breakdown:

Sites (Assigned):
├── View: ✓
├── Create: ✓
├── Edit: ✓ (full access)
├── Publish: ✓
├── Delete: ✗
└── Code Access: ✓

Code:
├── HTML: ✓
├── CSS: ✓
├── JavaScript: ✓
├── Custom Widgets: ✓
└── Head/Body Code: ✓

Advanced:
├── Site Settings: ✓
├── Integrations: ✓
├── Custom Forms: ✓
├── Advanced SEO: ✓
└── Schema Markup: ✓

Technical:
├── FTP Access: ✓ (if enabled)
├── Git Integration: ✓
├── Dev Mode: ✓
└── Site API: ✓

Use Cases:

• Front-end developers
• Technical consultants
• Integration specialists
• Senior developers

Key Differences from Designer:

• Code editor access
• Custom widget creation
• Advanced technical settings
• Integration configuration

Site Contributor

Purpose: Limited content editing on specific sites

Key Capabilities:

• Content editing: Add/edit content only
• Media uploads: Add images and files
• Blog posts: Create and edit blog content
• Cannot: Change design, publish, access settings

Permission Breakdown:

Sites (Assigned):
├── View: ✓
├── Edit: ✓ (content only)
├── Publish: ✗ (requires approval)
└── Design: ✗

Content:
├── Text: ✓
├── Images: ✓ (upload/replace)
├── Blog Posts: ✓
├── Products: ✓ (content only)
└── Forms: ✗

Design:
├── Layouts: ✗
├── Styles: ✗
├── Widgets: ✗ (can't add/remove)
└── Colors/Fonts: ✗

Settings:
├── Site Settings: ✗
├── SEO: ✗ (basic only)
├── Publishing: ✗
└── Analytics: ✓ (view only)

Use Cases:

• Content writers
• Blog contributors
• Product managers (content updates)
• Marketing interns

Workflow:

1. Contributor edits content
2. Changes saved as draft
3. Designer/Developer reviews
4. Designer/Developer publishes

Best For:

• Content-only updates
• Non-technical team members
• External contributors
• Quality control workflows

Client Access (Separate System)

Client Permissions

Purpose: Give clients access to their specific site

Not a team member role - separate permission system:

View Stats Only

Capabilities:

Analytics:
├── Visitor stats: ✓
├── Page views: ✓
├── Traffic sources: ✓
└── Reports: ✓ (export)

Site:
├── View: ✓ (preview only)
├── Edit: ✗
├── Publish: ✗
└── Settings: ✗

Use for:

• Clients who want to monitor performance
• Reporting-only access
• Stakeholder visibility

Edit Content

Capabilities:

Content:
├── Text editing: ✓
├── Image upload: ✓
├── Blog posts: ✓
├── Product content: ✓
└── Media library: ✓

Design:
├── Layout changes: ✗
├── Style changes: ✗
├── Widget add/remove: ✗
└── Responsive: ✗

Publishing:
├── Save drafts: ✓
├── Publish: ✗ (requires approval)
└── Unpublish: ✗

Use for:

• Clients managing their own content
• Content approval workflows
• Ongoing content updates

Full Edit

Capabilities:

Content:
├── Full content editing: ✓

Design:
├── Layout changes: ✓
├── Style changes: ✓
├── Add/remove widgets: ✓
├── Responsive editing: ✓
└── Theme changes: ✓

Publishing:
├── Publish: ✓
├── Unpublish: ✓
├── Backup/Restore: ✓
└── Site settings: Limited

Restrictions:
├── Delete site: ✗
├── Transfer site: ✗
├── Custom code: ✗
├── Advanced settings: ✗

Use for:

• DIY clients with design freedom
• Long-term client control
• Reduced ongoing support needs

Caution: Client can significantly change design

Reset Site (No Access)

Removes all client access:

• Can't view site
• Can't access stats
• Can't edit content
• Site hidden from client dashboard

Use for:

• Project completion
• Contract ended
• Transitioning to agency-managed

Site-Level Permissions

Per-Site Access Control

Each team member can have different permissions per site:

Team Member: John Doe (Role: Designer)
├── Site A: Full Edit + Publish
├── Site B: Edit Only (no publish)
├── Site C: View Stats Only
└── Site D: No Access

Permission Levels Per Site

Full Edit:

• Complete design and content control
• Publish changes
• Manage site settings
• Access analytics

Limited Edit:

• Content changes only
• No design modifications
• Can't publish (requires approval)
• View analytics

Stats Only:

• Analytics access
• No editing capabilities
• View-only preview
• Export reports

No Access:

• Site hidden from user
• Can't view or edit
• No stats access

Site Groups

Organize sites into groups:

Settings → Sites → Site Groups → Create Group

Benefits:

• Assign team members to entire group
• Bulk permission management
• Logical organization (by client, project type, etc.)

Example structure:

Site Groups:
├── Client A Sites (5 sites)
│   └── Team: Designer 1, Developer 1
├── Client B Sites (3 sites)
│   └── Team: Designer 2, Developer 1
└── Internal Sites (2 sites)
    └── Team: All Admins

Multi-Account Permissions (White Label)

White Label Hierarchy

For agency/reseller accounts:

White Label Master Account
├── Agency Team (your staff)
│   ├── Admin: Full access to all sub-accounts
│   ├── Designers: Access to assigned sub-accounts
│   └── Developers: Access to assigned sub-accounts
├── Sub-Account 1 (Client A)
│   ├── Client A Staff: Limited to their account
│   └── Sites: 10 sites
└── Sub-Account 2 (Client B)
    ├── Client B Staff: Limited to their account
    └── Sites: 5 sites

Cross-Account Permissions

Agency staff access:

• Can access multiple sub-accounts
• Permissions set at master level
• Restricted or full access per sub-account

Client staff access:

• Limited to their sub-account only
• Can't see other clients
• No master account access

Advanced Permission Scenarios

Custom Permission Combinations

Example 1: Content Manager (Hybrid)

Base Role: Designer
Custom Restrictions:
├── Can edit content: ✓
├── Can edit design: ✓
├── Can publish: ✗ (requires approval)
├── Can delete: ✗
└── Sites: Assigned only

Use: Content-heavy sites with design flexibility

Example 2: QA Specialist

Base Role: Site Contributor
Custom Additions:
├── View mode: ✓
├── Comment/Annotate: ✓
├── Test publish: ✓ (staging)
├── Live publish: ✗
└── Sites: All (view only)

Use: Quality assurance workflows

Temporary Access

Time-limited permissions (manual process):

1. Add team member with appropriate role
2. Set calendar reminder for removal date
3. Document expected duration
4. Remove access on scheduled date

Use for:

• Contractors
• Seasonal workers
• Project-based access
• Temporary elevated permissions

API Permissions

API Access Control

Who can generate API credentials:

• Account Owner: ✓
• Admin: ✓ (view only, can't regenerate)
• All others: ✗

API permissions scope:

• Full API access (all endpoints)
• Site-specific API keys (if supported)
• Webhook configurations

Security considerations:

• API credentials = full account access
• Limit API key distribution
• Rotate keys regularly
• Monitor API usage logs

Permission Best Practices

Principle of Least Privilege

Grant minimum permissions needed:

Bad:

Intern → Admin role
Reason: "Easier than managing specific sites"

Good:

Intern → Site Contributor role
Sites: Assigned 2 specific sites
Permissions: Content editing only
Review: After 30 days

Role Selection Guide

Choose role based on needs:

Security Recommendations

Critical permissions to protect:

• Custom code access (XSS risk)
• Team management (privilege escalation)
• API credentials (data exposure)
• White label settings (branding)
• Billing access (financial)

Protection measures:

• Limit Admins to 1-2 people
• Regular permission audits
• Monitor team activity logs
• Use site-specific access
• Enable two-factor authentication

Regular Permission Audits

Quarterly review:

• List all team members
• Verify role appropriateness
• Check site access
• Identify over-permissioned users
• Remove inactive accounts
• Update documentation

Audit script (via API):

async function auditTeamPermissions() {
  const members = await getDudaTeamMembers();

  const report = members.map(member => ({
    name: `${member.first_name} ${member.last_name}`,
    email: member.email,
    role: member.role,
    siteCount: member.site_permissions.length,
    lastLogin: member.last_login,
    daysInactive: calculateDaysSinceLogin(member.last_login)
  }));

  // Flag inactive users (90+ days)
  const inactive = report.filter(m => m.daysInactive > 90);

  return { report, inactive };
}

Troubleshooting Permission Issues

User Can't Access Expected Feature

Debug steps:

1. Verify role: Check assigned role
2. Check site access: Confirm site in access list
3. Permission level: Verify site-level permissions
4. Account status: Ensure active, not pending
5. Browser cache: Clear cache and retry

Common issues:

• Wrong role assigned
• Site access not granted
• Limited permissions on site
• Invitation not accepted

Can't Publish Site

Role requirements: Designer, Developer, or Client (Full Edit)

Check:

• User role allows publishing?
• Site-level permissions include publish?
• Site in draft mode?
• Client permissions set correctly?

Team Member Sees Wrong Sites

Causes:

• Site access not configured correctly
• Wrong site group assignment
• Cached site list

Fix:

1. Edit team member
2. Review site access list
3. Remove incorrect sites
4. Add correct sites
5. Save and have user refresh

Client Can't Edit Content

Verify:

• Client permissions set to "Edit Content" or higher
• Not set to "Stats Only"
• Invitation accepted
• Using correct login

Fix:

• Update client permissions
• Resend invitation
• Clear browser cache

Next Steps

• Adding & Removing Users - User management workflows
• Duda User Management - Overview and best practices
• Duda Help Center

Related Resources

• Duda Team Management Guide
• Client Permissions
• White Label Account Structure
• Team API Documentation