Hi everyone! 👋 I've been diving deep into our identity management stack lately and a project has come up that I'm really excited (and a little nervous) about. We're looking to finally automate our user lifecycle by integrating Ping Identity (we use PingFederate and PingDirectory) with Workday, specifically for those joiner, mover, and leaver (JML) events.
I know conceptually it's a common pattern—Workday as the source of truth for HR data, provisioning accounts and access in downstream systems via Ping. But I'm craving some real-world, ground-level details from anyone who has actually built this before. The documentation gives you the "what," but I'd love to hear about the "how" and the "gotchas."
My main questions are:
* **Connector Choice:** Did you use the out-of-the-box Workday connector for PingDirectory, or did you go a more custom route using the PingFederate Provisioning STS? I'm weighing the ease of a pre-built connector against the flexibility of a custom SCIM integration.
* **Attribute Mapping & Transformation:** This is where my methodical side really comes out! Workday's attribute names can be quite different from our LDAP schema. How did you handle complex mappings or deriving values? For instance, building a `cn` from `GivenName` + `Sn`, or determining group membership based on department, location, and title?
* **The Mover Scenario:** Joiners and Leavers seem straightforward, but Movers make me pause. What was your strategy for handling role changes, department transfers, or manager updates? Did you find it cleaner to treat some mover events as a "remove and re-add" to groups, or did you build precise delta logic?
* **Error Handling & Logging:** What did you do for monitoring and reconciling failures? I'm thinking about scenarios like a Workday event firing but a target system (like an application behind PingFederate) being down.
* **Performance with Large Datasets:** We have a sizable workforce. Any issues with initial bulk syncs or during peak times like Monday morning onboarding?
I'd be so grateful to hear about your experiences—not just what worked, but what you'd do differently if you started over. A side-by-side comparison of the different integration approaches would be an absolute dream for me.
Thanks in advance for sharing your wisdom! This community is always so helpful.
test everything twice
Attribute mapping is indeed where the real project costs hide, both in initial build and ongoing maintenance. We found Workday's calculated fields invaluable for pre-formatting data before it even hits the connector, reducing the transformation logic needed inside Ping. For example, generating a `preferredUsername` field in Workday that combined first initial and last name per our corporate standard saved us a custom function.
The bigger, often overlooked, cost is schema drift. When HR adds a new custom field in Workday, or your InfoSec team mandates a new required attribute in PingDirectory, you're touching this mapping logic again. We built a small staging table to log the raw Workday payloads and the transformed outputs, which has been crucial for debugging these changes. Without that audit trail, you're blind to why provisioning broke after a seemingly unrelated Workday update.
I'd also suggest a rigorous review of what you consider an authoritative source for each attribute. Should a department change in Workday overwrite a manually-set department in PingDirectory? Defining those rules upfront avoids political battles later when an executive's assistant changes their title in Active Directory and it gets clobbered by the next sync.
null
Absolutely right about schema drift. That's the silent killer of these integrations once the initial go-live champagne is flat. The staging table for payloads is smart, we did something similar but as a read-only mirror in our logging cluster.
My addition: you have to version your mapping logic explicitly. Not just document it, but treat it as code with a release cycle. We made the mistake of editing the transformation scripts directly in the Ping interface for "quick" changes. Six months later, a "rollback" was impossible because we didn't know which of the five ad-hoc edits had introduced a new dependency on a Workday field that HR later deprecated. Now we store all mapping as Jinja templates in Git, applied via the Ping API, with a clear version tag tied to each deployment. It adds a step, but it means we can answer "what changed?" instantly.
Also, the point about authoritative sources is critical. We hard-coded a rule that only a subset of Workday attributes (like employment status, department code, location) are authoritative. Everything else, especially display-name and title, is flagged as "HR suggested" but can be overridden by the department's internal system. It stopped so many fights.
Show me the benchmarks
The out-of-the-box Workday connector for PingDirectory works great for straightforward provisioning. We went with it and have zero regrets. The setup time saved was huge.
On your attribute mapping question: the connector's transformation language is pretty powerful, but lean on Workday calculated fields as much as possible. We pre-built the `displayName` and `mail` attributes there, which kept our mapping logic in Ping super simple, just a direct pass-through.
One gotcha we hit, though: the connector's default handling for "mover" events when an employee changes managers. It triggered a full modify, which was noisy and unnecessary for our use case. We had to tune the event filters to only care about department or location changes for access purposes.
Let the machines do the grunt work
Thanks for sharing this, it's super helpful to hear from someone just starting out like me. I'm looking at a similar project and the attribute mapping part already sounds daunting.
When you talk about using Workday calculated fields, is that something you set up in Workday itself before the data even reaches Ping? I'm trying to figure out who needs to be involved from the HRIS team on our side.
Also, the mover event noise issue user756 mentioned is interesting. Did you end up filtering events in Ping or in Workday? Trying to understand where that logic should live.
CloudNewbie
You've highlighted the core tension perfectly: pre-built connector speed versus custom SCIM flexibility. I chose the custom route via the Provisioning STS, and my long-term data supports that decision. While the out-of-the-box connector gets you to a basic sync faster, its transformation engine became a bottleneck for our complex, multi-target provisioning logic.
The "how" for attribute mapping in a custom setup is to treat Workday as a generic SCIM source and implement your transformation logic in a dedicated middleware service. We used a small Go service that consumed the SCIM events from Workday via the STS, applied mappings using versioned JSONata expressions stored in Git, and then dispatched to PingDirectory *and* other systems like our HR portal. This decoupling meant schema drift in one downstream system didn't force reconfiguration of the core Workday-Ping link.
The gotcha? Latency. You're adding a processing hop. We had to instrument the service to log full event timelines, which revealed that Workday's own event batching was the real culprit during peak onboarding periods, not our service. The raw numbers showed a 95th percentile delay of 8.2 seconds from Workday event to directory update, which was acceptable for our use case but required setting that expectation with the business early.