RPA bot receives 'Access Denied' error during automated case creation for employee onboarding

BPM Mendix
, , , , , , , ,
1

We’ve implemented an RPA bot that automates employee onboarding case creation in our Mendix case management system. The bot authenticates via a service account and calls a microflow to create onboarding cases, but it’s consistently failing with ‘Access Denied’ errors.

Microflow call from bot:


POST /api/cases/create
{
  "employeeId": "EMP001",
  "caseType": "Onboarding"
}

The microflow creates a Case entity and associated Task entities, but fails when trying to commit. We’ve verified the service account has the ‘CaseManager’ role, but we’re still getting access denied errors. This is blocking our entire onboarding automation and causing significant delays. The entity access rules seem correct for the role, but something’s not working with the microflow security or role-based permissions for the bot user.

2

Let me provide a comprehensive solution addressing microflow security, entity access configuration, and role-based permissions for your RPA bot scenario.

1. Microflow Security Configuration: First, verify your microflow security settings:

  • Open the CreateOnboardingCase microflow
  • Right-click → Properties → Security tab
  • Ensure ‘Apply entity access’ is set appropriately (recommend TRUE for production)
  • Verify ‘Allowed roles’ includes ‘CaseManager’
  • Check if ‘Execution’ is set to ‘Microflow’ level, not ‘Entity’ level

Critical microflow pattern for RPA bots:


CREATE Case (with System.owner = $ServiceAccount)
SET $Case/CaseType = 'Onboarding'
SET $Case/Employee = $Employee
CREATE Task over Case_Task association
SET $Task/Status = 'Pending'
COMMIT $Case, $Task

The key is explicitly setting the owner to the service account when creating entities.

2. Entity Access Configuration: For the CaseManager role, configure comprehensive entity access rules:

Case Entity:

  • Create: Yes
  • Read: XPath constraint: [System.owner = ‘[%CurrentUser%]’ or ‘CaseManager’ in ‘[%UserRoles%]’]
  • Write: Same as Read
  • Delete: Same as Read

Task Entity:

  • Create: Yes
  • Read: XPath: [Case_Task/Case/System.owner = ‘[%CurrentUser%]’ or ‘CaseManager’ in ‘[%UserRoles%]’]
  • Write: Same as Read

Employee Entity (associated):

  • Read: Yes (CaseManager needs read access to set associations)
  • Write: No (unless bot needs to update employee data)

Department Entity (associated):

  • Read: Yes
  • Write: No

The access denied error often occurs when trying to set associations to entities the role cannot read. Even if you’re just linking existing objects, the role needs read permission on those entities.

3. Role-Based Permissions for RPA Bot: Create a dedicated service account with proper role configuration:

  • Create user: ‘svc_onboarding_bot’
  • Assign role: ‘CaseManager’ AND ‘SystemIntegration’ (custom role for API access)
  • Do NOT use the Administrator role for service accounts (security best practice)

SystemIntegration Role Configuration:

  • Module roles: CaseManagement.CaseManager
  • Entity access: All entities used in automated processes
  • Microflow access: Only the specific microflows called by RPA bots
  • Page access: None (service accounts don’t need UI access)

Critical Configuration Steps:

  1. Check Association Access: For every association your microflow sets, verify the service account role has read access to the target entity. This is the most common cause of access denied errors.

  2. Review Event Handlers: Check Case and Task entities for before-commit/after-commit events. These execute with the current user’s permissions and may fail if they access entities the service account cannot read.

  3. Enable Security Logging: Add to your after-startup microflow:


SET LogLevel for 'Security' to 'TRACE'
SET LogLevel for 'EntityAccess' to 'DEBUG'

This will show exactly which entity operation fails and why.

  1. Test with Debugger: Use the Mendix debugger to step through the microflow execution as the service account user. This reveals exactly where access is denied.

Common Pitfall - System Module Entities: If your Case entity has associations to System.User or System.Image, the CaseManager role needs explicit read access to these system entities. Add entity access rules for System module entities in your security configuration.

Validation Checklist:

  • [ ] Microflow allowed roles includes CaseManager
  • [ ] Case entity: Create + Read/Write access for CaseManager
  • [ ] Task entity: Create + Read/Write access for CaseManager
  • [ ] Employee entity: Read access for CaseManager
  • [ ] Department entity: Read access for CaseManager
  • [ ] All association target entities: Read access minimum
  • [ ] No event handlers requiring elevated permissions
  • [ ] Service account has both CaseManager and API access roles

Implementing these configurations systematically will resolve your access denied errors and enable the RPA bot to successfully create onboarding cases.

3

Priya’s on the right track. Also verify the microflow itself doesn’t have additional security constraints. In Mendix 10.6, microflow-level security can restrict execution to specific roles. Go to the microflow properties and check the ‘Allowed roles’ setting. The service account’s role must be in that list. We had a similar issue where the microflow was restricted to User role but the service account only had SystemUser role.

4

Checked both suggestions. The microflow has CaseManager in allowed roles, and entity access shows read/write for Case and Task entities. But I’m wondering if there’s an issue with associations? The Case has associations to Employee and Department entities that might need access too?

5

Check if your microflow has ‘Apply entity access’ enabled. If it does, the service account needs explicit read/write access to all entities used in the microflow, not just the Case entity. Tasks, related Employee entities, and any association entities all need proper access rules configured for the CaseManager role.