Merger offboarding automation enforces identical treatment for every departing employee regardless of which legacy company they came from. A single Make.com workflow with conditional branches — triggered by one unified HRIS separation record — handles access revocation, compliance documents, severance calculation, and audit trails simultaneously. Manual execution guarantees inconsistency. This blueprint eliminates it.

Merger offboarding is the highest-stakes version of a process most HR teams already find painful. Two legacy policy environments, two IT permission structures, two interpretations of what “fair treatment” means — all running simultaneously, at compressed timelines, under legal scrutiny. Manual execution guarantees inconsistency. Automation is the only approach that enforces identical standards for every departing employee regardless of which side of the deal they came from.

This guide walks through the exact steps to build that automated workflow spine in Make.com. For the broader architecture of offboarding at scale — covering layoffs and restructures alongside M&A — start with the parent resource on offboarding automation at scale during mergers, layoffs, and restructures. What follows drills into the merger-specific implementation.

Before You Build: Prerequisites, Tools, and the One Risk That Breaks Everything

Three prerequisites must be in place before you build a single scenario. Missing any one of them will cause the workflow to produce inconsistent results — the exact outcome you’re trying to prevent.

Prerequisites

• A single authoritative HRIS record for every employee. If the merged entity is still operating two HRIS systems, you need a data-sync layer or a confirmed source-of-truth system before automation can fire reliably. Make.com cannot compensate for fragmented employee data — it can only act on what it receives.
• A finalized, legally reviewed separation policy. The policy must specify separation types (voluntary, involuntary, role-elimination, transfer), severance schedules by tenure and legacy entity, benefit-continuation rules, and required notice periods including any WARN Act obligations. Your Make.com workflow encodes this policy — it cannot create it.
• Full IT system inventory for both legacy organizations. Every access credential, SaaS license, hardware assignment, and privileged account must be mapped before you automate revocation. An incomplete inventory means some access survives the separation.

Tools Required

• HRIS with API access or webhook capability (unified trigger source)
• Identity and access management (IAM) platform with automated provisioning/deprovisioning
• Make.com (workflow automation and conditional branching)
• Document generation tool with conditional logic support (for policy-variant compliance documents)
• Secure digital signature platform for separation agreements

Time Estimate

A full-scope merger offboarding automation build — including testing across both legacy entity branches — takes three to six weeks depending on the number of legacy IT systems requiring integration. A minimum-viable version covering unified trigger, access revocation, and compliance-document generation is operational in two weeks.

The One Risk That Breaks Everything

The single largest risk is building two parallel workflows — one per legacy company — instead of one unified workflow with conditional branches. Parallel workflows diverge. A unified branching workflow enforces a shared standard. Every step below assumes the unified architecture.

If your team needs a structured discovery pass before building, the OpsMap™ discovery process maps the process and policy gaps that cause automation failures — before a single scenario gets built.

Step 1 — Define the Unified Separation Record as Your Single Trigger

Every offboarding action must originate from one event: the creation or update of a confirmed separation record in the HRIS. This is your Make.com trigger, and it must be singular.

Map the separation record fields your automation will read: employee ID, legacy entity, separation type, separation effective date, manager ID, department, CBA affiliation (if applicable), and location. These fields are what your conditional branches will use in every subsequent step. If any field is missing or inconsistently populated across legacy entities, fix the data upstream before you build downstream logic.

Set your Make.com trigger as a webhook or scheduled HRIS poll depending on what your system supports. Webhook is preferred — it fires the workflow the moment a separation record is confirmed, giving access revocation the shortest possible lead time.

Do not use an email notification or a manager-submitted form as your trigger. Both are manual steps that introduce delay and inconsistency. The HRIS record is the source of truth. Everything else is downstream of it.

Step 2 — Build the Legacy-Entity Branch Logic Before Any Action Steps

Immediately after the trigger, your Make.com scenario routes to a Router module. This is where you separate legacy-entity policy logic without duplicating the entire workflow.

Create two primary branches: one for each legacy organization. Within each branch, add a second-level filter for separation type (voluntary, involuntary, role-elimination, transfer). This gives you a policy-accurate path for every combination of legacy entity and separation type — without building parallel workflows that will diverge over time.

Every branch shares the same downstream modules: access revocation, document generation, severance calculation, audit logging. The branches control what inputs those modules receive, not which modules run. This is the architectural decision that makes the workflow auditable and defensible.

Document your branch logic in a scenario note before you add a single action step. In a legal dispute over whether two employees were treated consistently, the branch logic documentation is your evidence.

Step 3 — Automate Access Revocation Across Both Legacy IT Systems

Access revocation is the step with the most legal and security exposure. It must fire automatically, not as a task assigned to someone to complete manually.

Build an IAM deprovisioning call as the first action module after your branch router. This handles the primary identity layer: Active Directory or Okta suspension, SSO deactivation, and corporate email disabling. Set the effective date from the separation record — not from the scenario execution timestamp — so that revocation aligns with the legally specified last day of employment.

After primary identity, build sequential modules for each legacy IT system inventory item: SaaS application licenses, VPN credentials, physical access badges, and any privileged or admin accounts. For legacy-entity-specific systems that only exist in one branch of the merger, scope those modules to the correct branch using your Router logic from Step 2.

Add an error handler on every revocation module. Make.com’s built-in error handling routes failures to a dedicated notification path rather than silently dropping them. A failed revocation that goes unnoticed is a security and compliance incident. Use an error route that logs the failure to a spreadsheet and sends an alert to IT and HR simultaneously.

For teams building their first access-revocation automation, the ways the Make MCP server changes automation for HR teams covers how to accelerate this build with AI assistance.

Step 4 — Generate Compliance Documents With Policy-Variant Logic

Merger offboarding requires policy-variant documents: the separation agreement for a voluntary resignation from legacy Company A looks different from a role-elimination notice for a legacy Company B employee covered by a CBA. Both must be accurate, both must be generated without manual intervention, and both must route to the correct signature flow.

Connect Make.com to your document generation tool. Use a template-per-document-type approach rather than a single template with extensive conditional sections — the latter creates documents that are harder to audit and easier to break with a template update. Your branches from Step 2 determine which template fires.

Feed the separation record fields from your trigger directly into the document template variables: employee name, effective date, severance amount (calculated in Step 5), benefit-continuation end date, and any entity-specific required disclosures. No manual data entry. No copy-paste from one system to another.

Route the completed document immediately to your digital signature platform. Include the employee, the HR lead, and legal if required by the separation type. Set expiration dates on signature requests — open signature requests on legally required documents are a compliance risk.

Step 5 — Automate Severance and Benefits Continuation Calculations

Severance calculation is where inconsistency between legacy entities causes the most legal exposure. If two employees with identical tenure and role classifications receive different severance amounts because someone applied two different formulas manually, that inconsistency will surface.

Build a calculation module in Make.com that reads tenure (calculated from hire date to separation effective date), legacy entity, separation type, and any CBA-specific multipliers from the separation record. Output: severance amount in dollars, number of severance payment installments, benefit-continuation end date, and COBRA notification trigger date.

Pass these calculated values into both the document generation module (Step 4) and the payroll system update module. The payroll module should write the severance schedule directly — not hand off a number for someone to enter manually.

For benefits continuation, build a timed trigger: a Make.com scheduled scenario that fires on the COBRA notification date, pulling from the same separation record. This ensures no notification is missed because someone forgot to set a calendar reminder.

Step 6 — Build the Audit Trail From Day One, Not as an Afterthought

An automated workflow without an audit trail is not a compliant workflow. Every action your Make.com scenario takes must be logged with a timestamp, the employee ID, the triggering event, and the outcome.

Create a dedicated audit log destination — a spreadsheet, an Airtable base, or a database table — and write a logging module that runs after every major action in the scenario: trigger receipt, branch selection, access revocation completion, document generation, document signature receipt, severance calculation output, payroll update confirmation. Each log entry includes the Make.com execution ID so you can pull the full scenario run if a specific action is disputed.

Build a summary notification that fires when all steps complete for a single employee. Route it to HR and the employee’s manager. The notification confirms that all offboarding actions executed and includes a link to the Make.com execution log. This closes the loop and gives HR a timestamped record of completion without requiring them to manually check each system.

For managers and HR leaders who want a broader view of what consistent automation looks like across the OpsMesh™ framework — from discovery through ongoing management — the OpsMesh framework overview covers how these builds fit into a structured operations architecture.

What Consistent Enforcement Actually Looks Like in Practice

The goal of this entire build is one outcome: every departing employee in a merger — regardless of legacy entity, separation type, tenure, or department — moves through an identical process that applies the same policy rules, generates the same document types, and produces the same audit evidence.

That outcome is not achievable with manual execution. HR teams working under merger timelines, managing two legacy policy environments simultaneously, will make inconsistencies. Not because they’re careless — because the task is impossible to execute consistently at volume without systematic enforcement.

Make.com enforces it. The branch logic encodes the policy. The modules execute without variation. The audit log proves it.

Teams that start here — with a mapped process, a legal-reviewed policy, a full IT inventory, and a unified trigger — build workflows that hold up to scrutiny. Teams that skip the prerequisites and build fast end up with two parallel workflows, diverging policies, and the exact inconsistency they were trying to prevent.

The OpsMap audit process exists to prevent that outcome. Run it before you build, not after something breaks.

For HR teams managing inherited operational complexity beyond merger offboarding, the guide to fixing broken HR operations for small HR teams covers the broader triage and recovery framework.