The Power Automate branching problem you've described — an 18x40 matrix of location × department × role × access requirements that produced a "delicate scaffold of nonsense" — is a direct consequence of trying to encode a matrix in a sequential conditional logic engine. Power Automate is built for linear workflows with branching. Your onboarding problem is fundamentally a pattern matching problem: given a user's attributes, find the matching set of access requirements and execute them all. These are different architectures.

The FriedFred comment in this thread identified the right abstraction: pattern matching, where each action has criteria that evaluate independently, rather than a branching tree where every combination requires its own conditional path. The challenge is implementing this without programming skills in an enterprise environment.

Why Power Automate Hits a Ceiling Here

Power Automate is excellent for a defined set of use cases: linear workflows with a manageable number of branches, where each branch represents a distinct path rather than a combination of attributes. It works well when you have "if department is Engineering, do X" as an isolated condition.

It breaks down when conditions combine multiplicatively. Location × Department × Role with 18 categories of access across 40+ roles means the combination space is larger than any conditional tree can represent cleanly. Every new office, new title, or new access category multiplies the branching complexity. The "102 variables all saying Job Title" to cover every option in a multi-section form is the symptom — the branching logic can't be simplified without changing the underlying architecture.

The M365 dynamic group "contains" operand gap is a real limitation you've correctly identified. Mail-enabled security groups (MESG) don't support dynamic membership rules at all. M365 groups support dynamic membership but come with Teams channels and SharePoint sites you don't want. This is a genuine constraint of the Microsoft toolset that no amount of Power Automate configuration resolves.

The ApoplecticMuffin pattern — SharePoint list as a state tracker, CSV comparison for daily delta, separate PA flows per use case — is a well-reasoned DIY approach that works for organizations with the time to build and maintain it. The limitation is that it's custom infrastructure you own: when the HRIS changes its export format, when a new access category is added, when a new office opens, the flows need updating. This is the same "delicate scaffold" problem at a higher level.

The Architecture That Scales: Modular Playbooks Instead of Branching Conditions

The approach that handles your matrix without encoding every combination is to separate the attribute evaluation from the action execution and structure access provisioning as composable modules.

Birthright access as the universal base. Every employee, regardless of location, department, or role, needs a common set of tools: M365 E1, the company's communication platform, security tools. This is a single playbook that runs for every new hire, regardless of any other attribute. It's unconditional.

Location, department, and role as independent condition selectors. Instead of "if Location=DC AND Department=Logistics AND Title=Driver then do [all the things]," you have three separate evaluation layers:

• Location-based modules: "If Location=DC, run the DC location module" — which handles building access notifications, DC-specific tools, DC office manager task
• Department-based modules: "If Department=Logistics, run the Logistics module" — which handles logistics-specific applications and email groups
• Role-based modules: "If Title=Driver, run the Driver role module" — which handles the specific role entitlements

Each combination of location + department + role runs three independent modules that compose, rather than one branch in a tree that has to anticipate every combination. Adding a new office means adding one new location module, not updating the entire branching logic. Adding a new role means adding one new role module. The matrix complexity doesn't compound.

How Zluri Implements This for Your Specific Problem

Birthright playbooks + condition-based modular playbooks. Zluri's playbook architecture uses a WHEN–CONDITIONS–THEN structure that evaluates independently for each module. The onboarding trigger fires when the HRMS creates a new user record; each playbook evaluates its conditions against the user's attributes and executes if the conditions match.

For your D.C. Driver example: the birthright playbook runs for everyone (M365, Slack), the D.C. location playbook runs when Location=D.C. (building access notification, mobile device provisioning task), and the Driver role playbook runs when Title=Driver (company phone provisioning, specific badge access). Three clean modules, not one branch with 40 conditions.

HRIS CSV via SFTP — your specific constraint. Your HRIS doesn't support webhooks or direct API integration; it exports a daily CSV via SFTP. Zluri's HRMS integration supports CSV-based ingest as a source connection. The platform detects delta (new records, changed records, terminated records) from sequential CSV imports, which addresses the comparison logic the ApoplecticMuffin approach builds in PA/SharePoint.

Hardware and physical provisioning via manual task module. Laptops, badges, business cards, and physical IDs can't be auto-provisioned via API. Zluri's manual task module creates a tracked task — assigned to the specific task owner (office manager for badges, IT coordinator for laptops) — as part of the onboarding playbook. The task has a unique ID, a deadline, and a completion status that must be marked done to close the onboarding record. For teams using Jira as their service desk, manual tasks can generate Jira tickets automatically so IT follows existing workflows while the governance platform maintains the audit trail.

Stakeholder approval for access requiring it. The engineering coordinator's file share access that requires approval from a system owner routes through the access request module rather than the auto-provisioning playbook. The hiring manager's form shows only the applications relevant to their location and department (filtered app catalog), captures mandatory custom fields (project code, access duration), and routes automatically to the appropriate approver via email or Slack.

Solving the M365 Group Membership Problem

The M365 dynamic group "contains" operand gap is a real constraint. A few approaches that work around it:

Attribute standardization as the upstream fix. If job titles are standardized with consistent prefixes (all engineers at any location have titles starting with "Engineer-"), standard string matching (starts with, equals) works instead of "contains." This requires HR data hygiene work but eliminates the operand problem at the root.

IGA platform as the group membership manager. Rather than relying on M365 dynamic group rules, Zluri manages group membership directly through provisioning actions. When the Driver playbook runs for a D.C. user, one of its actions adds the user to the specific email distribution groups that driver role requires. The group membership is managed through playbook execution rather than dynamic rules — which gives you the "contains"-equivalent logic in the playbook conditions without requiring it from M365's group engine.

Use security groups for access control, not distribution lists for communication. For access control purposes (SSO apps, building access control, file shares), Entra ID security groups managed through Zluri playbooks work cleanly. For email distribution, consider whether Power Automate can manage the DL membership based on the same attributes — the two problems (access control and email routing) don't need to be solved by the same group type.

What This Looks Like at Your Scale

At 50 offices, 40+ roles, and 18 access categories, the playbook library might look like:

• 1 universal birthright playbook
• ~50 location-specific playbooks (one per office)
• ~8-12 department playbooks
• ~40 role playbooks

Total: ~100-103 playbooks, each maintained independently rather than a single branching flow encoding every combination. Adding office #51 means adding one location playbook. Adding a new role means adding one role playbook. No other playbooks change.

Each playbook is independently testable: run the D.C. Driver combination and verify that all three relevant playbooks execute correctly without any others running unexpectedly.

Frequently Asked Questions

How do you automate employee onboarding across 50+ offices with different access requirements?

The architecture that scales is modular playbooks that evaluate independently — a universal birthright access playbook for all employees, plus location-specific, department-specific, and role-specific playbooks that compose based on attribute matching. This avoids encoding every combination as a branch in a conditional tree, which becomes unmaintainable as offices and roles grow. Each playbook is independently configurable and independently maintainable.

Why does Power Automate struggle with complex multi-dimensional onboarding logic?

Power Automate executes sequential conditional logic — if/then branching. When access requirements depend on combinations of attributes (location AND department AND role AND access category), the number of branches grows multiplicatively. A 40-role, 18-category matrix requires hundreds of conditional combinations. Pattern-matching architectures, where each action evaluates its own criteria independently, scale significantly better for this problem type.

How do you handle onboarding when the HRIS only provides CSV exports?

CSV-based HRMS integration using daily delta detection — comparing each new CSV export against the previous one to identify new hires, terminations, and attribute changes — works for HRIS systems that don't support API or webhook integration. The comparison logic detects the delta and triggers appropriate provisioning, mover, or offboarding workflows without requiring real-time API integration.

How do you provision physical hardware (laptops, badges) in an automated onboarding workflow?

Physical hardware requires human action that can't be automated via API. A manual task module within the onboarding playbook creates a tracked task assigned to the appropriate owner (IT coordinator, office manager) with a completion deadline and status tracking. The onboarding record is not closed until the task is marked complete, ensuring physical provisioning is tracked rather than left to informal processes.