Workday Reports Available as Web Services

Workday Reports Available as Web Services

In Workday, the following report types can be exposed and called as web services for integrations:

1) Report-as-a-Service (RaaS) Reports
Purpose: Designed for API-based consumption.
Usage: Scheduled or on-demand data delivery (e.g., nightly payroll feeds).

Methods:

Launch_Report (SOAP/REST)
Supports XML, JSON, CSV outputs.

2) Advanced Reports

Includes:

Matrix Reports (flattened to XML).
Composite Reports (combined datasets).
Trending Reports (historical data).

Method: Get_Report (SOAP).

3) Search Reports

Simple tabular data (e.g., employee lists).

Methods:

Get_Report (SOAP).
RaaS (Launch_Report) if enabled.

4) BIRT Reports

Purpose: Formatted documents (PDF/HTML).
Method: Get_BIRT_Report (SOAP).

Example: Pay stubs, tax forms.

5) Analytics/Embedded Reports

Purpose: Visual/tabular analytics.
Method: Analytics REST API.

Key Validation Points (Interviewer Expects)

✅ "Available as Web Service" must be enabled in report properties.
✅ Integration user needs "Report Web Service" permissions.
✅ Matrix Reports work but output flattened XML (not native hierarchy).

Example Use Case (Bonus Points)
"In my project, I used RaaS to sync an Advanced Report (Employee Compensation) to SAP via Launch_Report. The report was scheduled nightly in XML format, filtered by active employees only."

Common Pitfalls to Avoid
❌ Saying "All reports can be web services" (only enabled ones).
❌ Forgetting BIRT requires Get_BIRT_Report, not Get_Report.

Final Tip:
"Always verify the report’s ‘Available as Web Service’ checkbox and test in the Web Services Test Form before integration."

Step-by-step navigation to check Integration IDs (WID, Reference IDs, External IDs) in Workday?

Step-by-step navigation to check Integration IDs (WID, Reference IDs, External IDs) in Workday?

1. Check WID (Workday Identifier)

Path:

Go to Worker Profile (Search: "Find Workers")
Select the employee → Click "Related Actions"
Choose "View Integration IDs"
Locate the "WID" field (128-bit UUID format).

2. Check Reference IDs

Path:

Navigate to "Maintain Reference IDs" (Search: "Maintain Reference IDs")
Select the object type (e.g., Worker, Position)
View/Edit the Reference ID Definitions (e.g., Employee_Reference_ID).
For API Testing:
Use Workday Web Services → SOAP/REST API Tester to see Reference IDs in API responses.

3. Check External Reference IDs

Path:

Go to Worker Profile → "Business Title" section
Click "View External IDs"
See/manually update fields like External_Employee_ID.

For Custom External IDs:

Search: "Maintain Custom Fields"
Locate your custom field (e.g., Legacy_HR_ID).

Pro Tips

Security: Ensure you have "View Integration IDs" permission.
Bulk Export: Use Reports (RaaS) with Worker_Integration_IDs data source.
API Access: Reference IDs appear in Get_Workers API responses.

What are the Essential PICOF Integration Services

What are the Essential PICOF Integration Services

PICOF (Payroll Interface Common Output File) integrations require three core components to run smoothly:

Payroll Interface MQ – Triggers the integration process.

Payroll Interface – Generates the final payroll output file.

Payroll Interface Parameters – Controls what data is included (like pay periods).

These services work together to ensure accurate and efficient payroll data transfers. 🚀

1)Payroll Interface MQ

Purpose: Initial service that triggers the PICOF integration.
Function: Loads and queues payroll data for processing.

2)Payroll Interface

Purpose: Core template that generates the output file.
Function: Transforms Workday payroll data into the required XML format.

3)Payroll Interface Parameters

Purpose: Define what data gets extracted.
Critical Parameters:

Pay Period: Filters data for specific payroll cycles.
Pay Period Selection:

Key Notes

These services work together to:

✅ Extract payroll data.
✅ Filter by pay period.
✅ Generate the final PICOF XML file.

Total Services: While Workday lists ~40 related services, these 3 are the most critical for basic PICOF setups.

What is the difference between PICOF and PECI ?

What is the difference between PICOF and PECI ?

PICOF (Payroll Interface Common Output File)

Captures only "Top of the Stack" (latest/final values).
Excludes reversed/recinded transactions (no audit trail).
Generates a single XML file (all paygroups combined).
Best for: Simple, high-volume payroll runs where only current data matters.

PECI (Payroll Effective Change Interface)

Captures "Full Stack" (all changes, including history).
Handles reversed/recinded transactions (full audit capability).
Generates separate XML files per paygroup.
Best for: Complex payrolls needing traceability (e.g., retro pay, corrections).

Clarified jargon:

Recinded Transactions
Meaning: A payroll transaction that was reversed/canceled (e.g., a bonus paid in error and rolled back).

Key Impact:

PICOF: Ignores recinded transactions (only shows final values).
PECI: Tracks recinded transactions (full audit trail).

Example:

Jan 1: $1,000 bonus (paid)
Jan 5: Bonus recinded (reversed)

PICOF: Shows nothing (net change = $0).
PECI: Shows both payment + reversal.

"Top of the Stack" = latest values only
"Full Stack" = complete transaction history

Added use cases for clarity.

Example Scenario

Employee Action: 10% raise → later 5% deduction.

PICOF Output: Only shows final 5% net increase.

PECI Output: Shows both transactions + timestamps.

Workday CCW: The Complete Guide to Core Connector Worker Integrations

Workday CCW: The Complete Guide to Core Connector Worker Integrations

Workday's Core Connector Worker (CCW) is mainly used to sync delta changes (like new hires, job updates, or terminations) since the last integration run. It does this using date launch parameters—specifically, "A L A L" (As of Entry Date, Last Successful Entry Date, As of Effective Date, Last Successful Effective Date). These dates help CCW track only new or modified data, making daily syncs efficient.

While CCW is optimized for delta changes, it can also do full data loads by setting date parameters to the past or using a "Full File Extract" option. However, for large initial syncs, Report-as-a-Service (RaaS) is often better.

Key specs:

Supports up to 200 fields (but performance slows near the limit).
Uses the "Create Integration System" task code.
Template name: "Core Connector Worker".

How many mandatory integration services in CCW?

Workday's Core Connector Worker (CCW) requires four mandatory integration services to function properly.

1.ESB Service (Enterprise Service Bus)
2.Date Launch Parameters
3.Eligibility Criteria (Field Override)
4.Integration Maps

ESB Service
The integration engine that executes CCW, handling data routing and transformation.

Date Parameters
Time filters ("A L A L") that control which data changes get synced.

Eligibility Criteria
Rules filtering which workers/fields to include (e.g., active staff only).

Integration Maps
Field-to-field mappings between Workday and external systems.

All 4 are essential - ESB runs the process, dates select what to sync, eligibility refines the scope, and maps define how data translates.


What is the use of ESB service ?

-This service is used for executing ccw integration, without this service we cannot execute any integration service.
-The ESB (Enterprise Service Bus) service is the engine that powers CCW integrations.
-Without the ESB service, CCW integrations simply won't run. Its main jobs are:

Managing the entire integration process from start to finish
Transforming data between Workday and external system formats
Handling errors and retries if something goes wrong
Ensuring data gets delivered to the right destination

What is date launch parameters in CCW?

Workday CCW uses Date Launch Parameters to filter which worker data gets synced. These four parameters (remember "A L A L") track changes based on timestamps:

-As of Entry Date – Syncs changes added to Workday after this date (e.g., new hires entered in the system).
-Last Successful Entry Date – Automatically saves the last sync date for entry-based changes.
-As of Effective Date – Syncs changes taking effect after this date (e.g., future promotions).
-Last Successful Effective Date – Tracks the last sync for effective-dated changes.

Why it matters:

By default, CCW syncs only delta changes (new/modified data since the last run).
For a full data load, set all dates to the past (like 01/01/2000).
Never leave dates blank—it can cause incomplete syncs or errors.

Example: If your last sync ran on June 1, setting As of Entry Date = June 2 ensures only fresh changes are pulled. The ESB service then processes these filtered updates.

1. As of entry date
2. Last successful entry date
3. As of effective date
4. Last successful effective date.

<< A L A L >>

Comprehensive Guide to Workday Integration IDs

Comprehensive Guide to Workday Integration IDs

What Are Integration IDs in Workday?

Integration IDs are unique identifiers used to reference Workday objects (e.g., employees, organizations, positions, cost centers) in integrations with external systems (e.g., payroll, ERP, HRIS, or financial systems). They ensure accurate data mapping and synchronization between Workday and third-party applications.

Why Are They Important?

-Prevent data mismatches (e.g., sending payroll data for the wrong employee).
-Enable real-time updates between Workday and external platforms.
-Support hybrid environments (e.g., when migrating from legacy systems).

Types of Integration IDs in Workday

1) Workday Integration ID Types
WID (Workday Identifier)

Generated by: Workday (system-assigned).
Format: 128-bit UUID (e.g., b3d8a3f7-1a2b-4c5d-8e9f-0a1b2c3d4e5f).
Editable?: ❌ No (immutable).
Purpose: Unique internal identifier for all objects.
Mandatory: ✅ Yes (all integrations rely on WID).

2) Reference ID

Generated by: System or user-defined (via ID Definitions).
Format: Configurable (text, number, etc.).
Editable?: ✅ Yes (properties can be modified).
Purpose: Used in APIs to reference objects (e.g., <wd:Employee_Reference>).
Mandatory: ✅ Yes (for API-based integrations).

3) External Reference ID

Generated by: User (manually maintained).
Format: Free-form (matches external system needs).
Editable?: ✅ Yes.
Purpose: Maps Workday objects to external system IDs (e.g., SAP_Employee_Code).
Mandatory: ❌ No (optional for integrations).

Key Clarifications

WID = Workday’s universal backbone (never changes).
Reference ID = Flexible pointers for APIs/web services.
External ID = Bridge for external systems (e.g., payroll providers).

Example:

An employee has:

WID: b3d8a3f7... (system-generated, immutable).
Reference ID: EMP_10025 (used in API calls).
External ID: ADP_789 (matches payroll system).

How It Works:

When querying an employee via API, Workday returns a Reference_ID instead of the raw UUID.

Example API snippet:

xml
<wd:Employee_Reference>
<wd:ID wd:type="Employee_ID">b3d8a3f7-1a2b...</wd:ID>
</wd:Employee_Reference>

What are Integrations In Workday?

What are Integrations In Workday?

Integrations connect Workday with external systems to automate data flow—ensuring seamless updates without manual work.
(or)
Automated data communication between two systems (like Workday ↔ Slack or Workday ↔ Bank, etc.).

Inbound Integration:
✅ Data is imported into Workday from external sources like:

-3rd-party systems (e.g., banks, payroll vendors)
-Flat files (e.g., CSV, XML)
-APIs/web services (e.g., time-tracking tools)

Example:
"A bank sends a daily .CSV file of employee loan deductions into Workday—this is an inbound integration."

Outbound Integration:
✅ Data is exported from Workday to external systems like:

-HR tools (e.g., Slack, ADP)
-Flat files (e.g., reports sent via email)
-APIs (e.g., pushing data to IT systems)

Example:
"Workday sends a .TXT file of terminated employees to your IT team to deactivate accounts—this is an outbound integration."

Simple Definitions:

Inbound: Data enters Workday (from outside).
Outbound: Data exits Workday (to outside).