Why coexistence is the right frame
When enterprises evaluate a workforce intelligence platform, the first question from the HRIS team is rarely about AI. It is about integration risk. Will this system conflict with our HCM? Will it create shadow data? Will it break our security model?
These concerns are legitimate. Workday installations represent years of configuration: business processes, security policies, custom reports, calculated fields, and approval chains. Any external system that touches Workday must respect that investment.
Gloat approaches Workday as a coexistence partner. The platform reads workforce data to fuel its Intelligence Engine. It writes back only when a governed action requires updating the system of record. And it maps its own access controls to Workday’s security group model so that data visibility in Gloat never exceeds what the user would see in Workday itself.
The three API surfaces
Workday exposes multiple integration interfaces. Gloat uses three, each for a distinct purpose.
| API surface | Protocol | Direction | Primary use case | Typical payload | Latency profile |
|---|---|---|---|---|---|
| RaaS (Report as a Service) | REST / SOAP | Outbound from Workday | Bulk extraction of worker profiles, positions, org hierarchy | Thousands to hundreds of thousands of records | Minutes (batch) |
| Workday REST API | REST (JSON) | Outbound from Workday | Real-time lookups for individual workers or positions | Single record or small sets | Sub-second to seconds |
| Workday Web Services (WWS) | SOAP (XML) | Inbound to Workday | Transactional write-back: job changes, gig assignments, skill updates | Single transaction per call | Seconds (synchronous) |
RaaS for bulk extraction
RaaS is the workhorse. Workday’s reporting engine is mature and highly configurable. Customers build custom reports that expose the fields Gloat needs: worker ID, preferred name, business title, supervisory organization, job profile, skills, certifications, and location.
Reports run on a schedule, typically daily, though some customers configure more frequent runs for high-velocity data like gig assignments. RaaS supports incremental extraction through effective-dated filters, pulling only records that changed since the last sync rather than re-extracting the entire population.
A critical advantage: RaaS respects Workday security natively. The report runs in the context of an Integration System User (ISU), and the ISU’s security group memberships determine which records appear. If the ISU lacks visibility into a supervisory organization, those workers do not appear in results.
REST for real-time reads
When a manager opens Gloat and views a recommendation, the platform may need the latest data for that worker. Waiting for the next RaaS sync is not acceptable. The REST API provides sub-second lookups for individual records.
Gloat uses REST selectively. Bulk operations through REST would hit rate limits and degrade performance for other integrations. REST fills gaps between batch syncs: confirming a worker’s current role before presenting a mobility recommendation, checking headcount status before suggesting a transfer, or validating span of control before routing an approval.
SOAP for transactional writes
Workday Web Services is the path for write-back. When a gig assignment is confirmed or a lateral move approved, the data change must flow back to Workday. WWS provides transactional APIs for operations like Change Job, Add Additional Job, and Update Worker Profile.
SOAP may seem archaic, but it remains Workday’s most capable write interface. The REST API supports a growing set of write operations, but WWS covers the full breadth of business objects. For complex transactions involving business process workflows, effective dating, and reason codes, WWS is the reliable path.
Security group mapping
Workday’s security model operates on the principle that every piece of data has an owner, and access is granted through security group membership.
| Security group type | How membership is determined | Typical use in Gloat integration |
|---|---|---|
| Unconstrained | Manually assigned to users. No data-level restriction. | Rarely used for Gloat. Grants overly broad access. |
| Constrained | Tied to a relationship (e.g., “manager of” a supervisory org). Access scoped to that relationship. | Primary model. Manager sees direct reports’ data in Gloat because the constrained group limits visibility. |
| Intersection | Combines two or more security groups. User must be a member of all to gain access. | Cross-functional scenarios (e.g., HR partner who also manages a region). |
| ISSG | Assigned to an Integration System User. Defines what the integration can read and write. | Controls Gloat’s own API access. Scoped to the minimum data domains needed. |
| Segment-based | Restricts access to specific segments within a business object (e.g., compensation, personal data). | Ensures Gloat reads job-related fields but not sensitive data unless explicitly required. |
The mapping principle: a user’s visibility in Gloat must never exceed their visibility in Workday. When a manager sees recommended candidates, every candidate must be someone the manager could also see through Workday’s native reporting.
Gloat achieves this through a two-layer approach. The ISU powering RaaS and REST connections is configured with an ISSG granting read access to the full worker population. This allows the Intelligence Engine to build a complete workforce picture for matching. At the presentation layer, Gloat applies access policies that mirror the requesting user’s Workday security group memberships. The engine reasons broadly; the governance layer filters narrowly.
This separation matters. Without it, matching quality would degrade for managers with narrow visibility, because the engine would have a smaller candidate pool. With the separation, matching quality is uniform across the organization, but visibility is appropriately constrained.
Handling security group changes
Security group memberships are dynamic. A promoted manager gains visibility into additional organizations. An HR partner who moves regions loses visibility into former teams. For customers with strict compliance requirements, Gloat supports event-driven sync through Workday’s Business Process Framework notifications, triggering immediate cache invalidation so that access changes propagate within minutes.
Write-back governance: the three-layer model
Every write to the SoR must be intentional, approved, and auditable. Gloat enforces write-back governance through three layers, each of which must pass before a write reaches Workday.
Layer 1: Allowlist
A strict allowlist defines which write operations are permitted and which business objects they target. A typical allowlist includes: updating skills after a validated assessment, creating a gig assignment as an additional job, initiating a lateral move through Change Job, and recording a mentorship pairing. Everything not on the allowlist is blocked by default. The allowlist is configured jointly by Gloat’s implementation team and the customer’s Workday administrator.
Layer 2: Approval
Even allowlisted operations do not execute automatically. They enter an approval workflow handled within Gloat, within Workday, or both. A lateral move might require approval from the current manager, the receiving manager, and HR. Some customers configure a hybrid: initial approval in Gloat (where approvers see match scores and skill gap analysis) with final approval in Workday (where effective dating, reason codes, and compensation adjustments are enforced).
Layer 3: Audit
Every write-back operation is logged with full context: who initiated the action, what data was sent, which API endpoint was called, what response was received, and which approval chain was followed. The audit trail supports compliance investigations, troubleshooting (capturing full error responses from Workday validation failures), and continuous improvement of the allowlist and routing rules.
| Governance layer | Function | Controlled by | Failure behavior |
|---|---|---|---|
| Allowlist | Defines permitted write operations and target business objects | Joint: Gloat + customer Workday admin | Non-allowlisted operations silently blocked |
| Approval | Routes operations through configurable approval chains | Customer: Gloat workflows, Workday BPF, or both | Unapproved operations pending until approved or expired |
| Audit | Logs every write attempt with full context and outcome | Gloat platform (immutable, customer-accessible) | Logging failure halts the write; operations never unlogged |
Keeping the SoR sacred
When an organization designates Workday as the SoR for worker data, every other system defers to it. Gloat’s coexistence model is built around this commitment.
Inferred skills in Gloat are tagged as inferred, never as confirmed, until validated and optionally written back through the governed pipeline. Organizational hierarchy always flows from Workday; Gloat does not maintain its own org chart. Employment status changes (terminations, leaves, inter-entity transfers) are always read from Workday, never originated in Gloat.
This deference is a feature, not a limitation. The enterprise adopts Gloat without re-architecting its data governance model. The HRIS team retains full control over the authoritative record. Gloat adds intelligence on top without disturbing it.
Implementation considerations
ISU configuration. Scope the Integration System User to the minimum security groups required. Start read-only. Add write access only when the use case is validated and governance is agreed upon.
Report design. Design RaaS reports for incremental extraction with effective-date filters. For enterprises above 50,000 workers, incremental sync reduces extraction from hours to minutes.
Rate limiting. Cache REST API calls aggressively on the Gloat side, with invalidation tied to the RaaS sync cycle.
Testing. Validate write-back in a Workday sandbox: confirm non-allowlisted operations are blocked, approval routing works, and audit logs capture expected detail.
Monitoring. Track sync success rates, write-back approval rates, API error rates, and data freshness through integration dashboards.
The coexistence principle
Coexistence with Workday is an architectural philosophy. The HCM stores, enforces policy, and serves as the system of record. The intelligence platform reasons, recommends, and orchestrates. Each system does what it does best, and the integration layer ensures they work together without stepping on each other. The next article applies the same philosophy to SAP SuccessFactors, where the API landscape, security model, and write-back mechanics differ in important ways.
The goal of coexistence is not to hide the HCM. It is to let the HCM do what it does best, store and enforce policy, while the intelligence layer does what it does best, reason and recommend.
Key terms
Gloat integrates with Workday through three API surfaces: RaaS for bulk reporting, REST for real-time reads, and SOAP for transactional writes. Security group mapping ensures Gloat never sees data the requesting user cannot access in Workday itself. Write-back follows a three-layer governance model of allowlisting, approval, and audit. The system of record remains authoritative. Gloat is the intelligence layer, not a replacement.