Why Workday integrations usually stall, and what is different here
The standard objection to connecting a third-party tool to Workday is not really about the tool. It is that most integrations ask your Workday administrator to register something inside the tenant — a redirect URI, an application, a consent grant — and every one of those is a change request, a security review, and a queue.
QRBold's connector is built to avoid that entirely. It uses the grant types Workday's own "Register API Client for Integrations" flow is designed around: your team creates an Integration System User, mints a refresh token against it, and hands QRBold a credential. Authorisation-code is deliberately not implemented, because it would require QRBold's redirect URI in every customer tenant and buys nothing — there is no end user to consent, only a service account reading a directory.
The practical result is that the Workday-side work is a task your integrations team already knows how to do, using a pattern they have almost certainly used before, with nothing foreign left registered in the tenant afterwards.
How the refresh token is treated
A Workday refresh token deserves more care than an ordinary API key and gets it. Unlike an access token it does not expire on its own, and unlike a signing key it is not merely a way to prove identity — it is the grant itself. Anyone holding it can read your worker directory until a human revokes it in Workday.
So it is sealed at rest, never returned by any QRBold endpoint, never written to a log, and only ever transmitted to a host that has passed an allowlist check. Access tokens are held in memory and re-minted five minutes before expiry — a wide margin on purpose, because a full roster read of a large tenant takes minutes and a token that dies halfway through produces a 401 that reads like a permissions problem rather than a timing one.
Revocation is entirely in your hands: revoke the token in Workday and QRBold's next read fails closed, with nothing left in QRBold's database that could be replayed.
Reading the directory is not the same as handing out cards
The Workday connector fills a roster and does nothing else. It never creates a card on its own — the provisioning engine is the only thing in QRBold that creates a card, and it is driven by the rule you set, the preview you review, and the first run you confirm.
For an enterprise rollout this is the property that makes a pilot possible. You can connect a 40,000-worker tenant, read the entire directory, verify the field mapping against real records, and still have provisioned exactly zero cards. Then you enable Sales, check the results, and widen from there.
Workday alongside your identity provider
Most enterprises running Workday also run Okta or Microsoft Entra ID, and the two answer different questions. The identity provider knows who can sign in; Workday knows the employment facts — job title, department, worker type, termination date — and is usually the more authoritative source for what actually belongs on a business card.
The integrations are independent, so a common arrangement is SAML single sign-on through Okta or Entra ID for authentication, with Workday as the roster that decides who is eligible and what their card says. Neither integration requires the other.