Modified Core Connectors: The Workday Flex Credits Trap Nobody Talks About

Workday's Flex Credits policy gives a clear API exemption to "Workday pre-built, unmodified integrations including Core Connectors." That exemption is one of the biggest cost protections in the model. It means your standard payroll connector, your benefits carrier feed, your bank integration, and dozens of other Workday-delivered integrations don't count against your API entitlement.

But the exemption has one word that changes everything: "unmodified."

What counts as a modification

The policy draws a line between unmodified and modified Workday integrations. A modified connector is one where the customer or a partner has changed the Workday-delivered configuration. This can include:

Adding or removing fields. You needed an additional field in the payroll output that the standard connector doesn't include. A consultant added it during implementation. The connector now has a customization.

Changing filters or conditions. The standard connector exports all employees. You filtered it to exclude a specific worker type. That's a modification.

Adding transformations. The standard connector sends data in Workday's default format. You added an XSLT transformation to match your vendor's requirements. Modified.

Changing the schedule or trigger. This one is less clear. Changing when a connector runs may or may not constitute a modification depending on how the policy is interpreted. If in doubt, ask your Workday account team for written confirmation.

Augmenting with Studio. The Workday-delivered Core Connectors are exempt, but the policy specifically notes "unless augmented by Studio integrations." If you added a Studio flow that enhances or wraps a Core Connector, the augmented connector may lose its exemption.

The common thread: any change to the Workday-delivered template creates a risk that the connector is no longer classified as "unmodified" under the policy.

Why this matters more than you think

Core Connectors are some of the highest-volume integrations in a typical tenant. They handle payroll transmission, benefits enrollment, bank account updates, tax filing, and dozens of other critical data flows. Some run daily. Some run multiple times per month. All of them generate significant API traffic.

Consider a mid-market organization with 5,000 employees and 12 Core Connectors:

• Payroll connector: 2 runs/month, ~10,000 API calls per run = 240,000/year
• Benefits connector: daily eligibility sync, ~2,000 calls/day = 730,000/year
• Bank connector: 2 runs/month, ~5,000 calls per run = 120,000/year
• 9 other connectors at various frequencies: ~500,000/year combined

Total: roughly 1.6 million API calls per year from Core Connectors.

If these are all unmodified, none of this counts against your entitlement. If three of them have been customized, you might have 500,000 to 800,000 newly countable API calls per year. For an organization with a 2.5 million call entitlement, that's 20 to 32% of the budget consumed by integrations you assumed were free.

How to check your tenant

Step 1: Run the Integration Template Catalog report. This report classifies every integration in your tenant by template type. Workday-delivered integrations are identified as such. Custom integrations and modifications are flagged.

Step 2: Compare against your integration inventory. For each Workday-delivered connector, verify whether it's been customized. Check the integration configuration for any changes from the default template.

Step 3: Quantify the API traffic. For any modified connector, pull its API traffic from the PCC API Activity Reports. The Top API Request Sources report shows traffic by Integration System User. Map each modified connector's ISU to its traffic volume.

Step 4: Get written confirmation from Workday. For connectors where the modification status is ambiguous, ask your Workday account team for a written confirmation of whether the connector qualifies as unmodified under your specific policy version.

What to do if you find modified connectors

Option 1: Revert to unmodified. If the customization is minor and can be handled downstream (by the receiving system or middleware), revert the connector to its original template. The API traffic becomes exempt again.

Option 2: Replace with the current template. Workday updates Core Connectors with each release. The current template may include fields or features that weren't available when you originally customized. Check whether the current standard connector meets your requirements.

Option 3: Accept and budget. If the customization is essential and can't be moved downstream, accept that the connector's API traffic counts against your entitlement. Quantify it, include it in your forecast, and factor it into your renewal negotiation.

Option 4: Rebuild as an EIB or Studio integration. If the connector is heavily customized anyway, consider whether it should be rebuilt as a purpose-built integration. This doesn't change its counting status (custom integrations count), but it gives you more control over the API patterns, allowing optimization techniques like delta sync, batching, and caching.

The audit process

We recommend auditing your Core Connectors as part of any Flex Credits readiness review:

1. Inventory: List every Core Connector in your tenant with its template name, last-modified date, and ISU
2. Classify: Mark each as unmodified, modified (minor), modified (significant), or unknown
3. Measure: Pull API traffic for each modified or unknown connector from PCC
4. Quantify: Calculate annual API calls and the credit impact if those calls count
5. Decide: For each modified connector, choose revert, replace, accept, or rebuild
6. Confirm: Get written confirmation from Workday on any ambiguous classifications

The broader lesson

The Core Connector trap illustrates a principle that applies across the entire Flex Credits model: your billing outcome depends on classification details that were invisible before consumption-based pricing. An integration that was commercially identical to every other integration a year ago is now either free or countable depending on a single attribute (modified vs. unmodified).

This is why a Consumption Baseline Assessment matters. It's not just about counting API calls. It's about classifying every integration, mapping exemptions, and building a forecast that accounts for the rules as they actually apply to your specific tenant.

Frequently asked questions

If I modify a Core Connector now, does it retroactively count past traffic? No. The policy is forward-looking. Past API traffic during the grace period isn't charged regardless of classification. But once the grace period ends, the modified connector's ongoing traffic would count from that point forward.

Does modifying a connector in sandbox affect the production exemption? The modification status is per-environment. A connector can be unmodified in production and modified in sandbox. However, most organizations maintain the same configuration across environments, so a sandbox modification often indicates a production modification was also made.

Are Cloud Connect integrations treated the same as Core Connectors? The policy exempts "Workday pre-built, unmodified integrations including Core Connectors." Cloud Connect integrations are a separate category. Check your policy version for specific treatment of Cloud Connect.

Can a partner confirm whether a connector is modified? A partner can review the integration configuration and compare it against the standard template. For a definitive classification that affects billing, get written confirmation from your Workday account team.

Audit your integration portfolio with a Consumption Baseline Assessment, or estimate your exposure with our free Flex Credits Calculator.