Event-Driven Onboarding Automation for Nonprofit Human Services Organization
Client Profile
The client was a nonprofit human services organization with a wide mix of roles across programs, clinical services, and administration. Their new-hire equipment process depended entirely on someone remembering to start it. HR entered a new employee into the HRIS; at some later point a person noticed, worked out what that role needed, and opened a ticket with IT; IT then sourced a laptop, provisioned accounts, and configured software.
Every step of that chain worked, and the chain had no automatic trigger at the front of it. When the hand-off was slow or missed, the failure surfaced on the new hire’s first morning, with no laptop and no accounts. The organization also had no reliable view of which upcoming hires were still unequipped, and no systematic prompt to recover hardware when someone left.
Solution
We built an event-driven provisioning pipeline on Microsoft Fabric. Employee records, IT ticket history, and hardware inventory were ingested into a lakehouse and reconciled into a single clean record per employee, then modeled into a warehouse containing employee and position dimensions alongside asset-assignment and onboarding-ticket facts. A per-role requirements library was added, specifying the laptop model, SSO access, and software needed for every position number in the organization.
A trigger watches the employee table continuously. When a new employee ID appears, it fires a webhook carrying the employee and position details to an automation layer, which looks up that role’s requirements in the warehouse and creates a fully pre-populated IT provisioning ticket in the service desk — the same system IT already worked in, with no manual data entry. A separate trigger fires on termination to prompt hardware recovery. A Power BI dashboard tracks orientation readiness, flagging any upcoming hire without an assigned laptop serial before their start date.
What is Event-Driven Automation?
Most data warehouses are read-only destinations. Data flows in from operational systems, and people query it to produce reports. The flow is one-directional, and the warehouse’s role ends at describing what happened.
Event-driven automation reverses part of that flow. Instead of waiting for a person to notice something in a report and act on it, a trigger watches for a specific condition in the data and initiates an action the moment the condition is met. In this case the condition is the appearance of an employee ID that has not been seen before, and the action is the creation of a provisioning ticket.
The distinction worth understanding is between polling and event-driven design. A polling approach runs on a schedule — check every hour, see what changed, act on it. Event-driven design instead defines the condition once and lets the platform watch for it, which removes both the lag between the event and the next scheduled check and the need to track what has already been processed.
The broader pattern is sometimes called reverse ETL or operational analytics: the warehouse stops being purely a place where analysis happens and becomes a source of action in the systems people actually work in. That framing matters for adoption. A dashboard requires someone to open it. A ticket appears in the queue IT already watches.
Points of Note Regarding Solution
Identity Resolution Across Systems That Never Agreed
The pipeline depends on knowing that an employee in the HR system, a requester in the ticket system, and an assignee in the asset inventory are the same person. None of these systems shared a common identifier, so identity had to be reconstructed.
Two problems compounded. The first was ordinary name variance — the same person recorded as Mikael in one system and Michael in another, with hyphenated surnames, honorifics, and inconsistent middle names throughout. We handled this with PySpark notebooks performing fuzzy matching and name normalization against the raw lakehouse data before anything reached the warehouse.
The second problem was harder. Historic tickets frequently carried no structured employee reference at all; the person’s name existed only inside the free-text ticket title, in a handful of conventions that had accumulated over years. We wrote a parser to extract names from those titles, and the important design decision was that it returns nothing rather than guessing. Titles matching known non-personal patterns are skipped entirely, and extracted text containing terms like “password,” “printer,” or “not working” is rejected as a false positive.
That choice trades recall for precision deliberately. An unmatched historic ticket is a small gap in a reporting table. A wrongly matched one attaches a real person to activity that was not theirs, and in a pipeline that provisions equipment, a confident wrong answer is considerably worse than a blank.
The Requirements Library Is Manual, and Should Be
The automation resolves a position number to a specific list of hardware, software, and access. That mapping was built by hand, position by position, and there was no way around it. It does not exist in any source system, cannot be reliably inferred from historic tickets, and represents institutional knowledge held across HR, IT, and program managers.
We want to be direct that this is the load-bearing element of the whole design. The pipeline, triggers, and dashboard are durable infrastructure. The requirements library is a living table that will drift the moment a new position is created, a software vendor is swapped, or a laptop model is discontinued. An automation that silently provisions against a stale library is worse than no automation, because it produces confident, wrong tickets that IT has been trained to trust.
So the honest framing of this engagement is that we did not remove the human judgment from onboarding. We relocated it. Instead of a person making a fresh decision about equipment every time someone is hired, a person maintains a definition of what each role needs, and that definition is applied consistently and immediately. That is a real improvement, and it depends on the library having a named owner and a review cadence. We flagged this as a standing operational requirement rather than a project task, because it is the one part of the system that cannot maintain itself.
Conclusion
The result is that a new hire entered in the HR system produces a pre-filled equipment ticket the same day, with no human hand-off in between, and an orientation-readiness dashboard surfaces any hire still missing a laptop while there is time to fix it. Terminations prompt hardware recovery rather than depending on someone remembering.
Two constraints are worth naming. The source pipelines run daily incremental loads, so “immediate” means same-day rather than same-minute — appropriate for a process measured in days before the start date, and not suitable if the requirement were instant. And the system reduces the manual work of onboarding without eliminating the manual work of maintaining what onboarding means, as described above.
The design goal throughout was to put the output where the work already happens. The provisioning ticket is created in the service desk IT already lives in, in the same format they already process, which is why the automation gets used rather than admired.
Bespoke Solutions for Your Organization
Boxplot is passionate about working with all clients, regardless of their previous level of experience in data. If your organization is looking for a solution similar to the one described in this article —or any other data-oriented capability— let us know by contacting us here.