Simple Object Designer Documentation
Index

Permissions Matrix

This page provides a reference for the permissions required for various Simple Object Designer operations.

Permission Sets Overview

Key Permission Sets

Permission Set Purpose
SUPER Full system access
D365 EXTENSION MGT Extension management
Snapshot Debugging Production symbol download

Operations and Required Permissions

Basic SOD Usage

Operation Sandbox Production
Open SOD SUPER or equivalent SUPER or equivalent
Configure settings SUPER SUPER
Create fields SUPER SUPER
Place fields SUPER SUPER
Create features SUPER SUPER

Symbol Download

Operation Sandbox Production
Download symbols SUPER or D365 EXTENSION MGT SUPER + Snapshot Debugging
OAuth authentication BC user account BC user account

Publishing

Operation Sandbox Production
Direct publish D365 EXTENSION MGT D365 EXTENSION MGT
Download .app D365 EXTENSION MGT D365 EXTENSION MGT
Install from .app D365 EXTENSION MGT D365 EXTENSION MGT

API Operations

Operation Required Permission
Create API endpoints SUPER
Access API (interactive user) Table-level permissions
Access API (Entra application) The permission set shipped with your SOD-published app, plus execute on the generated API page objects
Business logic APIs Codeunit execution permissions, plus the app's permission set for the tables the logic touches

Who needs the app's permission set

End users of your customizations. SOD-generated extensions ship a permission set covering the app's objects — custom fields, tables and pages. Users who need to see or use SOD custom fields must be assigned it.

Granting SUPER masks the requirement but is not the correct approach. If a field appears only for users with SUPER, that is the diagnostic: the app's permission set is missing from everyone else. See Common Issues.

API consumers authenticating as a Microsoft Entra application. Without the app's permission set assigned to the Entra app, reads and writes to newly created custom or feature tables fail with a permissions error, even while standard tables remain accessible.

Environment-Specific Requirements

Sandbox Environments

Sandbox is more permissive:

  • Symbol download with standard permissions
  • Easier deployment
  • Force Sync typically available

Production Environments

Production has additional requirements:

  • Snapshot Debugging for symbol download
  • More careful deployment practices
  • Consider change management

Granting Permissions

SUPER Permission Set

Assigned via:

  1. Users page in BC
  2. Select user
  3. Add SUPER permission set
  4. Apply to all companies (recommended for SOD)

D365 EXTENSION MGT

Assigned via:

  1. Users page in BC
  2. Select user
  3. Add D365 EXTENSION MGT
  4. Apply scope as needed

Snapshot Debugging

Assigned via:

  1. Business Central Admin Center
  2. Environment > Users
  3. Add permission

Or via Azure AD:

  1. Azure Portal > Enterprise Applications
  2. Business Central > Users
  3. Assign role

Permission Scope

Company-Level vs Tenant-Level

SOD typically needs tenant-wide permissions:

  • Symbol download is tenant-wide
  • Some operations span companies

Verifying Scope

Check permission assignment:

  • "(All Companies)" for tenant-wide
  • Specific company name for company-scoped

Common Permission Scenarios

New SOD User

Minimum for full SOD usage:

  1. SUPER permission set with a blank company specified — that is, assigned for all companies, not scoped to one
  2. For production symbols: Snapshot Debugging, also assigned with a blank company

If the SOD page cannot be found in a particular company, suspect permissions first. See Common Issues.

Limited User (API Only)

For users only consuming APIs:

  1. Read/write on relevant tables
  2. The permission set from the SOD-generated app, for its custom and feature tables
  3. Execute permission on the SOD-generated API page object(s) — a data-only set such as "SUPER (Data)" does not cover them. The page numbers depend on your Object Prefix and object numbering, and a single endpoint may map to more than one page object.
  4. No SOD design permissions needed

Interactive BC users often already have Page 0 (all pages) access, which is why they never hit the page-permission problem; dedicated service principals typically do not.

Service-to-Service / Entra Application Access

For an Entra (Azure AD) application consuming SOD-generated APIs through OAuth application permissions:

  1. Azure AD API permission — Dynamics 365 Business Central > API.ReadWrite.All, or something narrower. This grants access at the API layer only.
  2. The permission set included with your SOD-published app, assigned to the Entra application on the Microsoft Entra Apps page in Business Central. This is what grants access to the underlying tables.
  3. Execute permission on the generated API pages.
  4. Permissions scoped to the company being called, or to all companies.

These are separate layers. Without the app's permission set, the application can authenticate and succeed on some APIs while failing on others — a business logic call such as "Release Sales Document" touches many tables and fails without it.

See Consuming APIs.

Developer Handoff

For developers continuing in VS Code:

  1. GitHub repository access
  2. BC development permissions
  3. Standard dev environment access

Troubleshooting Permissions

"Access Denied" Errors

Check:

  1. User has SUPER or equivalent
  2. Permission assigned to correct companies
  3. Permission set is active

Symbol Download Fails

Check:

  1. Sandbox: SUPER or Extension Management
  2. Production: SUPER + Snapshot Debugging
  3. Tenant-level scope

Publish Fails

Check:

  1. D365 EXTENSION MGT assigned
  2. User can access Extension Management
  3. No conflicting permissions

Best Practices

Principle of Least Privilege

  • Grant only needed permissions
  • Review periodically
  • Remove when no longer needed

Documentation

  • Document who has SOD permissions
  • Note why permissions were granted
  • Track permission changes

Auditing

  • Review SOD usage periodically
  • Check who has published recently
  • Maintain accountability