Flowchart showing OneLogin webhook trigger routing through role lookup, existence check, and five paths to Create, Activate, Deactivate, or Update User in myAvatar

·

OneLogin to Netsmart myAvatar – User Lifecycle Management Automation

Overview

A behavioral health provider needed employee account changes in Netsmart myAvatar/myUnity to stay in sync with OneLogin, without staff manually creating, updating, or deactivating accounts every time someone joined, changed roles, or left. I built a Zapier automation that listens for user events in OneLogin, checks the person’s current status in myAvatar, and routes the request to the correct API call — create, activate, deactivate, or update — based on that status.


What the customer wanted

  • User accounts in myAvatar to reflect current employment and role status automatically, without manual lookups
  • Correct handling for each type of event coming out of OneLogin:
    • New hires who don’t yet have a myAvatar account
    • Employees being onboarded who already have an existing (inactive) account
    • Employees being offboarded who have an active account
    • Title/role changes for employees who already have an account
    • Title/role changes for employees who don’t yet have an account
  • No duplicate accounts created for people who already exist in myAvatar
  • Role/permission assignment to be driven by a lookup table rather than hardcoded in the Zap

What I built

A single Zap with a webhook trigger, a role lookup, an existence check, and a five-way path split that calls the appropriate myAvatar API endpoint for each scenario.

  • A webhook trigger that receives user data pushed from OneLogin whenever a user is created or updated
  • A Zapier Tables lookup that resolves the user’s role and determines the correct permission set before any API call is made
  • A “Does User Exist” check against myAvatar to determine whether the person already has an account
  • A 5-branch Path step that routes each event to the correct action:
    • New Employee – No Account → Create User
    • Onboarding – Existing Account → Activate User
    • Offboarding – Account Exists → Deactivate User
    • Title Change – Account Exists → Update User
    • Title Change – No Account → Create User

How the automation works

1. Receive user data

The Zap triggers on an inbound webhook from OneLogin whenever a user record is created or modified. The payload includes the employee’s identifying info, employment status, and role/title.

2. Look up role and permissions

Before touching myAvatar, the Zap queries a Zapier Table to map the incoming OneLogin role/title to the corresponding myAvatar role and permission set. This keeps the role-to-permission mapping editable in one place instead of buried in Zap logic.

3. Check if the user already exists

The Zap calls the myAvatar API to check whether an account already exists for this person.

  • If no account is found, downstream paths treat this as a new account scenario.
  • If an account is found, downstream paths treat this as an existing account scenario.

4. Route to the correct path

The Zap evaluates the OneLogin event type together with the account-existence result and splits into one of five paths:

  • New Employee – No Account
    • Condition: event type is a new hire, and no existing myAvatar account was found
    • Action: Create User — provisions a new myAvatar account using the role/permissions resolved in step 2
  • Onboarding – Existing Account
    • Condition: event type is onboarding, and an inactive/existing myAvatar account was found
    • Action: Activate User — reactivates the existing account rather than creating a duplicate
  • Offboarding – Account Exists
    • Condition: event type is offboarding, and an active myAvatar account was found
    • Action: Deactivate User — disables access without deleting the account record
  • Title Change – Account Exists
    • Condition: event type is a title/role change, and an existing myAvatar account was found
    • Action: Update User — updates role and permission assignments on the existing account
  • Title Change – No Account
    • Condition: event type is a title/role change, but no myAvatar account was found
    • Action: Create User — provisions a new account using the updated role, so the change isn’t lost if provisioning hadn’t happened yet
Flowchart showing OneLogin webhook trigger routing through role lookup, existence check, and five paths to Create, Activate, Deactivate, or Update User in myAvatar
Workflow diagram: OneLogin event → role lookup → existence check → routed to Create, Activate, Deactivate, or Update User in myAvatar

Tools used

  • Zapier – orchestrates the webhook trigger, role lookup, existence check, and path routing
  • OneLogin – source system of record for employee lifecycle events (new hire, onboarding, offboarding, title change)
  • Zapier Tables – stores the role-to-permission mapping used to resolve access levels
  • Netsmart myAvatar/myUnity – target system where user accounts are created, activated, deactivated, and updated via API

Results & benefits

  • No manual account provisioning – new hires get a myAvatar account automatically instead of waiting on IT to create one
  • No duplicate accounts – the existence check ensures onboarding events reactivate an existing account instead of creating a second one
  • Faster offboarding – access is revoked as soon as the offboarding event fires in OneLogin, reducing the window where a departed employee still has access
  • Centralized role mapping – permission changes only need to be updated in one Zapier Table, not across multiple Zap steps

Leave a comment