New Hire Tickets That Work Themselves: Wiring HaloPSA to Power Automate

Your client fills out a new starter form in the HaloPSA self-service portal. By the time a technician would have opened the ticket, the user already exists in Microsoft 365 with a license, a manager, the right group memberships, and a welcome email queued for their start date. That is the build we are walking through here: HaloPSA as the front end, a webhook as the trigger, and a Power Automate flow in the client's tenant doing the work.

This is the sibling to our native Microsoft 365 onboarding tutorial, which uses Microsoft Forms as the front end instead of a PSA. Use that one when a client should submit requests directly in their own tenant; use this one when you want everything flowing through HaloPSA tickets.

The automation performs the following tasks:

• Creates the user in Microsoft
• Adds attributes like job title, department, and phone number
• Assigns a manager to the user
• Assigns a license to the user
• Sends an email to the user's manager, HR, or both
• Adds the user to groups, sites, and Teams
• Mirrors the access of another user (optional)
• Creates automated actions and notifications for business systems access
• Sends a welcome email to the user, including a template to set up Microsoft Authenticator

What does manual onboarding actually cost you?#

Before building anything, put a number on the problem. The math varies by MSP, but here is a simple equation:

Cost of onboardings = average number of onboardings x average time per ticket x blended technician rate x 0.5 (assuming you cannot automate the entire task list in most cases)

Worked example:

• Average onboardings: 75 per month
• Average ticket time: 2 hours
• Blended technician rate: $34 per hour

75 x 2 x 34 x 0.5 = $2,550 per month, or $30,600 annually

The dollars are only part of it. Add the 75 technician hours a month freed for other work, a tailored client experience, and a consistent process that takes human error out of the equation.

How the pieces fit together#

One design decision matters more than any other: the automation lives in each client's Microsoft environment, not yours. In Halo, that leaves you two ways to structure the front end:

• A global form used for all customers, with customizable field groups, where each customer gets their own webhook pointing to the Power Automate flow in their tenant
• A custom form per customer, each still pointing to its own unique webhook

Example form:

End to end, the sequence runs:

1. A customer fills out a new hire form from the self-service portal.
2. A webhook fires and kicks off the Power Automate flow in their tenant.
3. The user is created in Microsoft, assigned a manager, placed in a license group, and updated with the proper attributes.
4. An encrypted email goes out from a shared mailbox to their manager, HR, or both with the user details, including the password.

1. The user is added to groups, sites, and Teams, either from designated groups or by mirroring another user's access.
2. Specific actions chain to business systems, like email notifications.
3. The flow delays until the user's start date.
4. A welcome email goes to both their personal and work email. The work email contains the MFA setup guide.

What you need before you start#

On the HaloPSA side, you need admin rights to:

• Create and modify field groups
• Create webhooks

In the customer's Microsoft 365 tenant:

• Create a service account for the Power Automate flow. Something like automation@customerdomain.com works.
• License that account with Power Automate Premium. It costs $20 per month as of September 2024, and the webhook trigger requires it.
• Assign the service account the User Admin and Group Admin roles. The flow needs these rights to perform its actions.
• Create or reuse a shared mailbox for the auto-generated emails, for example EmployeeLifecycle@customerdomain.com.
• Create a group for license assignment, since the flow licenses users via group membership. If the client runs Business Premium, call it something like "Microsoft 365 Business Premium Users." Microsoft's docs cover group-based licensing in the admin center (opens in new tab) and assigning licenses to a group (opens in new tab).

The custom connector dead end, and why a webhook wins#

HaloPSA's own documentation points you toward creating a custom connector (opens in new tab). Save yourself the afternoon: as of September 2024, that path does not work. The failure appears to be an authorization code character limit in Microsoft that Halo has not fixed yet, and the community has documented it: Power Automate Connector issues on r/halopsa (opens in new tab).

A webhook is the alternative, and for this use case it is genuinely the better tool, not just the fallback:

• The webhook acts as a trigger the moment the form is submitted, which is exactly what the kickoff of this flow needs.
• What you lose is the connector's ability to call the Halo API as actions inside Power Automate, for example to write what the automation did back to the ticket. You could replace that with an HTTP trigger in Power Automate, calling the API directly, but then you have to pass in secrets and generate tokens securely, for example with Azure Key Vault. The action count roughly 10x's. We do not love it.

Setting up the webhook in HaloPSA#

1. In Halo, go to Configurations > Integrations > Webhooks > New.
2. Leave all fields default except the Payload URL (which comes from Power Automate in a moment) and Events.
3. Under Events, add an event for "New Ticket Logged."
4. Set the event triggers:
   • Client Name is equal to the client this webhook is for
   • Summary contains "Service Request: New Starter Request" (or whatever your form is called)

Setting up the trigger in Power Automate#

1. Go to https://make.powerautomate.com/ (opens in new tab).
2. Click + Create > Automated Cloud Flow, and skip the starter steps.
3. For the trigger, search for HTTP and select "When a HTTP request is received."

1. Change "Who can trigger the flow" to Anyone.

1. Power Automate will not save the flow or generate your webhook URL until at least one action exists. Add a placeholder: search for "Delay" and set 30 seconds.

1. Click Save. A URL appears in your HTTP action. Copy it and paste it into the Payload URL field of the Halo webhook.

1. Test by submitting a form tied to the trigger. You will see the results on both sides, in Halo and in Power Automate.

Building the form in Halo#

If you run Halo daily, you likely know its form tooling better than we do. The pieces this build uses:

• Custom Objects to create form fields like "Manager" and "Microsoft Groups"
• Field Groups to bundle those custom objects
• Ticket Types as the global form, or to create forms on a per-customer basis

If you have a cleaner way to structure this, we would genuinely like to hear it.

Grab the Power Automate template#

Rather than building every action by hand, you can import a ready-made template into each customer environment and customize from there: get the template (opens in new tab). The full video tutorial below walks through how every action is built.

Microsoft documents the import process here: Export and import your flows across environments with packaging (opens in new tab).

And the full walkthrough on video: watch the HaloPSA onboarding automation tutorial on YouTube (opens in new tab).

Where this build hits its ceiling#

With more time invested, four additions would round this out:

• HaloPSA API: with an HTTP request, the flow could interact with the Halo API directly, for example creating the new user as a contact in Halo at creation time (let us know if that already exists natively).
• PowerShell with Azure Automation: group-based licensing breaks down when the tenant is out of licenses. An Azure Automation runbook could check available license counts with PowerShell and assign directly instead of relying on group membership.
• Pax8 integration: using the Pax8 API, the flow could bump the license count when none are available and wait for provisioning before assigning the license to the user.

• Halo ticket updates: the API could also write what the automation performed back to the ticket.

Be honest about the complexity curve here. Once you are bolting on PSA writebacks, license provisioning, and distributor APIs, a purpose-built tool like Rewst (opens in new tab) becomes the better fit, because most of that integration comes out of the box:

• Integration with the customer's M365 tenant using your existing GDAP rights
• A single management portal instead of an automation deployed into every client tenant (which also simplifies things if a client offboards from you)
• Native integrations to Halo, Pax8, Twilio, and other MSP tools