Skip to main content
A request reaches a workflow one of two ways: your techs run it in Core, or your clients’ staff submit it from a link you share. Both routes record the request, raise a PSA ticket if ticketing is on, wait for approval if the workflow has one, then run the same workflow in the client’s tenant. Every run appears in Executions.

Your techs run it from Core

Anyone in your Core organisation clicks Run a workflow, picks the workflow and the client, and fills in that client’s form. The workflow must be Internal only or Internal + public. See Run a workflow.

Your clients use a live login

Each public workflow has one link for every client, listed on Public forms. Their staff open it, click Sign in with Microsoft and sign in with their usual work account: no Triggr account, and Triggr never sees their password. To offer a workflow this way, set it to Public form only or Internal + public. See Share your forms.

How Triggr knows the client

Every Microsoft 365 organisation has a tenant ID. When someone signs in, Triggr reads it and finds the client on Clients with the same Microsoft tenant ID. Nothing is set up per person: anyone at Acme Corp, with any Acme Corp account, gets Acme Corp’s form. Partner Center import and Look up from domain fill in the tenant ID; see Add your clients. The messages a visitor sees when no client matches are in Share your forms. The tenant ID only recognises the client. To do the work, the client must also be connected: linked to GDAP, or approved by its admin with a per-client app. Otherwise the request is recorded and the run fails at its first Microsoft step; see Fix Microsoft connection problems.

What the client’s settings change

Triggr builds the form and runs the workflow with that client’s settings: Base config, plus anything you’ve overridden for the client. See Settings for each client. Client staff see that a request needs approval, but never who approves it or what access it grants. Next: Set up Triggr Core.