Coexistence with SAP SuccessFactors: OData, RBP, Compound Employee

A different integration landscape

SAP SuccessFactors and Workday are both enterprise HCMs, but their integration architectures differ in fundamental ways. Where Workday consolidates around RaaS for bulk reads and SOAP for writes, SuccessFactors exposes a broader surface of OData APIs, each tied to a specific module. Where Workday uses security groups with constrained membership, SuccessFactors uses a three-dimensional Role-Based Permissions (RBP) model. And where Workday’s write-back runs through Web Services, SuccessFactors increasingly routes integrations through the SAP Business Technology Platform (BTP).

These differences matter for architects. A Workday integration playbook does not translate directly. The protocols differ. The security semantics differ. The write-back mechanics differ. And SuccessFactors has its own AI assistant, Joule, which raises a question Workday does not: how does an external intelligence layer coexist with a vendor-native AI?

OData v2 vs. OData v4

SuccessFactors does not expose a single API. It exposes dozens of OData endpoints, each corresponding to a module or business object. The protocol version varies by module, and the differences between v2 and v4 affect integration design.

Three practical impacts stand out for Gloat’s integration.

Incremental sync. OData v4’s native delta query support makes incremental extraction cleaner. With v2, the integration tracks the last sync timestamp and filters on lastModifiedDateTime, which requires careful handling of clock skew and does not capture deletions reliably. With v4, delta tokens track server-side state and the response includes created, updated, and deleted entities.

Deep profile extraction. Employee Central (v2) limits $expand depth, so pulling a worker’s complete profile often requires multiple round trips. The Compound Employee API solves this for standard fields, but custom MDF objects still require separate calls.

Write-back payloads. OData v4’s JSON-based batch operations are simpler to construct and debug than v2’s multipart MIME encoding, reducing implementation complexity for integrations that write through OData rather than BTP.

Gloat’s integration framework abstracts these differences behind a unified connector layer, handling protocol-specific details transparently.

The Compound Employee API

The Compound Employee API returns a worker’s complete profile as a single nested payload: personal information, employment details, job information, compensation, and more. A single call delivers what would otherwise require a dozen separate OData queries against individual entity sets.

For Gloat’s Context Engine, this is the primary extraction path. Three advantages matter most.

Atomicity. The payload is a point-in-time snapshot. There is no risk of reading job information from one sync cycle and compensation from another, which can happen with sequential entity queries if a change occurs between calls.

Efficiency. One Compound Employee call replaces 10 or more individual OData requests. For large populations, this keeps API call volume well within SuccessFactors’ rate limits.

Navigational completeness. The nested structure includes pre-resolved references to positions, departments, and cost centers that would require additional lookups in a flat model.

The tradeoff is flexibility. The API returns a fixed set of elements. Custom MDF (Metadata Framework) objects do not appear in the response. Gloat supplements Compound Employee extraction with targeted OData queries for custom entities. For workers with extensive job histories, payload size can be substantial; Gloat handles this through streaming deserialization rather than buffering entire responses.

RBP: the three-dimensional security model

SuccessFactors’ Role-Based Permissions model is conceptually different from Workday’s security groups. RBP defines access along three independent dimensions that intersect to produce a permission decision.

A permission role defines the verbs (view, edit). A permission group defines the nouns (which workers). Field-level access defines the adjectives (which attributes). The effective permission for any user-entity-field combination is the intersection of all three.

This three-dimensional model requires more granular mapping than Workday’s approach.

Integration user permissions. The API user powering Gloat’s extraction has a custom permission role granting read access to worker profiles, positions, skills, and job history. The permission group is set to the full population so the Intelligence Engine can build a complete workforce picture.

Presentation-layer filtering. When a manager uses Gloat, the platform applies field-level filtering that mirrors their RBP configuration. If their role excludes compensation fields, Gloat does not display compensation-derived insights for workers outside their scope. The engine may use compensation data internally, but the presentation layer respects RBP field access.

Permission group boundaries. If a user’s RBP limits visibility to a specific legal entity, Gloat filters results accordingly. A regional HR director who sees only Asia-Pacific workers in SuccessFactors sees only Asia-Pacific workers in Gloat.

Workday security is primarily about which records you can see. SuccessFactors RBP adds which fields you can see on those records, creating a finer-grained access matrix.

Intelligent Services for event-driven sync

SuccessFactors provides Intelligent Services, a set of event-driven triggers that fire on business transactions: new hires, terminations, job changes, compensation changes. These events trigger integration flows without polling.

For RBP-sensitive changes like permission role updates and organizational reassignments, Intelligent Services enables near-real-time propagation to Gloat’s access control layer. When a manager’s permission group changes, the event triggers an immediate cache refresh, ensuring visibility updates within minutes.

Write-back through BTP

Direct OData writes are supported for some entity types, but SAP increasingly recommends routing integrations through the Business Technology Platform. Gloat follows this guidance, routing write-back operations through BTP integration flows.

Validation. BTP flows apply SAP-native business rules before the write reaches Employee Central. If a job change requires a specific reason code or a compensation band constraint, the flow validates before committing. Failures surface clearly rather than as cryptic OData errors.

Orchestration. Some operations span multiple entities. A lateral move involves updating job information, adjusting position assignment, and creating a job history entry. BTP orchestrates these as a single transactional unit.

Auditability. BTP provides its own logging layer, complementing Gloat’s three-layer governance model. The customer’s integration team can monitor through SAP’s native tools (Cloud Integration monitoring, Alert Notification) alongside Gloat’s audit logs.

The three-layer governance model (allowlist, approval, audit) applies identically to SuccessFactors. Allowlisted operations are defined jointly. Approval chains are configurable. Audit logs are immutable. The middleware layer changes the plumbing but not the governance principles.

Joule coexistence: complementary, not competitive

SAP’s Joule is a generative AI assistant embedded across the SAP suite. It handles conversational HR interactions: checking PTO balances, approving time-off requests through natural language, looking up policy documents. Joule excels at making SAP workflows accessible through conversation.

Gloat’s agentic intelligence serves a fundamentally different purpose.

The coexistence boundary is clear. Joule handles transactions within SAP. Gloat handles intelligence across systems. An employee updating their address or requesting time off uses Joule. Identifying internal candidates for an open role, detecting flight risk from skill market trends, or orchestrating a multi-step talent review that draws from SuccessFactors, the LMS, and labor market data is Gloat’s domain.

The two systems reinforce each other. When Gloat’s matching agent identifies a candidate, the recommended action can surface in SuccessFactors where Joule helps the employee complete the transaction. When Joule handles a job change approval, the event propagates through Intelligent Services to Gloat, which recalculates affected recommendations.

Implementation patterns

Start with Compound Employee. Use it as the primary extraction path. Supplement with targeted OData queries for MDF custom objects and module-specific data outside the compound payload.

Use Intelligent Services for high-velocity events. Configure triggers for new hires, terminations, job changes, and org reassignments to feed Gloat’s real-time sync layer.

Route writes through BTP. Even when direct OData writes are possible, BTP provides validation, orchestration, and monitoring that justify the additional layer. These flows are reusable across integration scenarios.

Map RBP dimensions explicitly. Document the permission role, permission group, and field-level access for both the integration user and each end-user persona. Test that Gloat’s presentation-layer filtering matches expected RBP behavior.

Clarify the Joule boundary. Define which interactions belong to Joule and which to Gloat. Communicate this to end users so they know which tool to reach for.

The coexistence principle, applied

The same philosophy that governs Workday coexistence applies here: the HCM is the system of record, and Gloat is the intelligence layer. SuccessFactors adds a second coexistence dimension with Joule. The enterprise does not need to choose. Joule makes SAP more accessible. Gloat makes the workforce more intelligible. Together, they deliver conversational efficiency and strategic intelligence without forcing either system outside its strengths.