Skip to main content

Documentation Index

Fetch the complete documentation index at: https://human-resource-docs.ha-consultancy.com/llms.txt

Use this file to discover all available pages before exploring further.

Permission set

The extension ships exactly one permission set: Human Resource HAC (object 70003100), declared in BC-Human-Resource-AL/src/permissionSet/PermissionSet.HumanResourceHAC.al. It is Assignable = true so an administrator can assign it directly to users or include it in a higher-level permission set.

What it grants

ObjectPermissions
All HR-specific tables (70003101 – 70003160)RIMD (read, insert, modify, delete)
All HR-specific table extensionsRIMD
All HR-specific pagesX (execute / open)
All HR-specific reportsX
All HR-specific codeunitsX
Standard BC tables (Employee, Gen. Journal Batch, Resource, etc.)Not granted by this permission set. Combine with D365 BUS PREMIUM or one of the standard HR permission sets.
The matching XML manifest is BC-Human-Resource-AL/extensionsPermissionSet.xml, kept in sync for AppSource validation.
RoleRecommended permission sets
HR AdministratorHuman Resource HAC + D365 BUS PREMIUM
HR Officer (limited)A custom permission set derived from Human Resource HAC with RM (no insert/delete) on configuration tables, plus D365 BASIC
Employee self-service (mobile/portal app)A dedicated low-privilege user that only has access to the published API codeunits. The HR.API uses client credentials OAuth — no per-employee user permissions are involved on the BC side.
AppSource auto-publishMicrosoft handles this — no manual permission set assignment needed in production.

Adding the permission to a user

  1. Search for Users.
  2. Select the user → click Edit.
  3. On the Permission Sets FastTab, add Human Resource HAC.
  4. Confirm BC has applied it (the user’s effective permissions update on next session).

Field-level security

The extension does not define field-level permissions. Microsoft’s Field-Level Security framework can be layered on top by an administrator using standard BC tools, targeting fields like bank account number or salary amount.

What is intentionally not granted

  • Permission to delete companies — never something an HR user should do.
  • Permission to change permission sets — same.
  • Permission to modify the Permission Set HAC itself — to prevent privilege escalation, the permission set excludes itself from the modify rights.

API caller authorisation

The HR.API uses a fixed Entra ID application (registered by the partner) with client credentials. There is no per-employee API key. The mobile or portal app authenticates the end user some other way (typically Entra single sign-on) and asserts the employee number in each request body; the BC codeunits decide whether to honour that assertion based on the calling user’s BC permission set. To restrict who can call the API, deploy it behind an authenticated reverse proxy (Azure Front Door, API Management, etc.) or use Entra Application Roles.