Work instructions
Work instructions are essential resources for the Aptean Shop Floor Production (BC) extension and are primarily designed to be managed and stored within SharePoint. The system connects to SharePoint via app registration in the Azure portal, which acts as a bridge using a client ID and client secret. These instructions can be associated specifically with items or work centers within the Business Central environment, allowing them to be displayed based on operational requirements.
Difference between delegated and application permissions
In the Microsoft identity platform, permissions govern how applications gain access to protected resources, such as email or calendar data. Applications can access organizational data in two primary modes.
Delegated permissions
Delegated permissions (access on behalf of a user) are used in the delegated access scenario, where a client application accesses resources on behalf of a signed-in user.
| Aspect | Details |
|---|---|
| Identity Context | The application acts on behalf of a signed-in user. |
| Other Names | Scopes or OAuth2 permission scopes. |
| Authentication | Requires the user to sign in and grant consent (OAuth 2.0 Authorization Code Flow). |
| Permission Scope | The access of the application is determined by two factors: the delegated permissions or scopes granted to the client application, and the existing privileges of the signed-in user for the resource. The application cannot access any data or resource beyond what the user is authorized to access. |
| Use Case | User-centric applications, such as Web, Mobile, or single-page apps (SPA). |
| Consent | Users can consent their own data, or administrators can consent for all users. Consent methods can be static (configured list on app registration) or dynamic (requesting individual permissions at sign-in). |
| Visibility in Logs | Appears as user activity. |
For example, an application granted the Files.Read.All delegated permissions can only read files that the signed-in user can personally access.
Application permissions
Application permissions (access without a user), also known as app roles or app-only permissions, are used in the app-only access scenario, where the application acts independently, without a signed-in user present. This model is typically used for backend scenarios like automation or background services (daemons).
| Aspect | Details |
|---|---|
| Identity Context | The application acts as its own service principal, using its own identity. |
| Other Names | App roles, App-only permissions. |
| Authentication | Use the application credentials (client secret, certificate, or managed identity) via the Client Credentials Flow. |
| Permission Scope | Defined entirely by the application-level permissions granted by an administrator. The application is able to access any data that the permission is associated with. |
| Use Case | Web applications or daemon applications used for background daemons, automation scripts, or data sync agents. |
| Consent | Only an administrator can consent application permissions. The consent method is static only (configured list on app registration). |
| Visibility in Logs | Appears as a service principal activity. |
For example, an application granted the Microsoft Graph API's application permission Files.Read.All can read any file in the tenant using Microsoft Graph.
Determine the required permissions
You can choose the permission type based on how you want users to access work instructions.
-
Delegated permissions: Select this option if you want users to access work instructions only when they have permission to view the corresponding files in SharePoint.
-
Application permissions: Select this option if you want work instructions to be accessible in shop floor production, regardless of the user’s SharePoint permissions.