Payroll Outbound Integration Across Multiple Pay Groups

Hi @Kanak Johari​ , tagging in @Christopher Manson​ for validation and additional input. I think this is more IS related so I'll take a stab at it. Based on your description and the screenshots, I don't think the issue is with the Integration Studio report override filter. The bigger limitation is likely the Pay Run parameter that the payroll report itself requires.

What's happening

When a payroll report contains a Pay Run parameter, Dayforce Reporting executes the report in the context of a single pay run. Even if the report contains a Pay Group filter that allows multiple values, the selected Pay Run effectively anchors the report to one specific payroll commit.

In your example:

• Pay Run parameter = "Last committed pay run for Pay Group #100"
• Integration Studio override filter = Pay Groups 100, 200, 300, 400, etc.

The report still executes against the selected pay run for Pay Group 100, so the output only contains data associated with that pay run.

The override filter is only overriding report filters; it does not replace or expand the underlying Pay Run parameter context.

Why "No Data Found" appears

This is expected behavior for many payroll reports.

The autogenerated Pay Run parameter is often:

• Required
• Hidden/system-generated
• Used to establish payroll context

If no default value is provided, Integration Studio cannot resolve the parameter and therefore shows "No Data Found" or fails to retrieve report data.

Recommended approaches

Option 1: One integration per Pay Group (most common payroll pattern)

Create separate integrations for:

• PG100
• PG200
• PG300
• PG400
• PG500

and schedule them after payroll commit.

This is usually the safest and most supportable approach because payroll data is naturally organized by pay run.

Pros

• Supported payroll context
• Simple troubleshooting
• Consistent results

Cons

• Multiple integrations/files

Option 2: Use a report that does not require Pay Run context

If the business requirement is truly:

"Give me all committed payroll results across all pay groups"

then investigate whether the report can be redesigned to use:

• Pay Period End Date
• Check Date
• Payroll Run Date
• Payroll Commit Date

instead of the Pay Run parameter.

If the report no longer requires the Pay Run parameter, Integration Studio can override the Pay Group filter with multiple values and return all records.

The challenge is that many payroll result datasets in Reporting automatically introduce the Pay Run parameter and don't allow it to be removed.

Option 3: Use a payroll API source instead of Reporting

If the volume and complexity justify it, consider whether the GET Time Data or Quick Entry is more appropriate than a custom report.

However, based on the fields you've listed:

• Employee Number
• Pay Group
• Pay Period Number
• Pay Period End Date
• Earnings
• Taxes
• Deductions
• Gross
• Memos

a report-based solution is typically the easier path unless you hit reporting limitations.

What I would verify next

Open the report in Reporting and check:

1. Is the Pay Run parameter marked Required?
2. Is it system-generated by the payroll dataset?
3. Can the report run successfully in Reporting when:

• • multiple Pay Groups are selected
  • a single Pay Run is selected?

If the answer to #3 is yes but only one pay group's data appears, that confirms the Pay Run parameter is driving the result set and the Integration Studio behavior is expected.

Hi @Brenda Sutton​ , Thank you, that was really helpful. I’ll get those items sorted out.

I had one additional question regarding the client requirement. After the payroll commit, the client wants five separate output files: Gross Pay, Earnings, Deductions, Taxes, and Memos.

Is the recommended (or only) approach to generate these files through the DF link method, or can this also be achieved through Integration Studio?

Currently, I’m using a Custom Report as the data source in an Outbound Integration and scheduling the integration to run. Thanks for your guidance.

@Kanak Johari​ , If the requirement is to generate five separate files (Gross Pay, Earnings, Deductions, Taxes, and Memos) after payroll commit, Integration Studio can support this if the source data is available through a Custom Report. Since you're already using a report as the source for an outbound integration, creating separate integrations/files from that report would be a viable approach.

However, if the requirement is specifically to use post-commit payroll export data, DF Link/payroll export processes are typically the standard approach, as payroll export data isn't currently available as a native Integration Studio source.

In short: Report-based outputs can be handled in Integration Studio; payroll-export-based outputs generally require the payroll export/DF Link route.

Hi @Brenda Sutton​  Thank you for the above information. It is really helpful.

Hi @Brenda Sutton​ , Happy Monday! Hope you are doing great.

I’m working on a Sun Life integration and the requirement is for an inbound file. I’ve reviewed the available options, but I don’t see any out-of-the-box import type or prebuilt connector that matches the file layout they’ve provided. Below is the File format the provided -

Header Indicator|File Sequence ID/Policy Number|Company ID|Payroll Spreadsheet Run Date|Company Name|File Type|Payroll Period From Date - To Date MMDDYYYY|Frequency Monthly/Biweekly|Record Count (including Header)|Member Count

Could you please guide me on the initial setup? Specifically, which import type would be best to use to configure this custom file structure?

Thanks in advance for your help.

Hi @Kanak Johari​  - I apologize for my delayed response...been on vacation for the last couple of weeks:-) From the file layout you've shared, I'd recommend using the Build My Own (Inbound File) connector, as I don't believe there's a prebuilt connector or import type that matches this custom Sun Life format.

One question though—is the layout you posted just the header? To recommend the appropriate Dayforce import target, we'd need to see the detail/member record(s) and understand what data is being imported (for example, payroll deductions, benefit elections, employee data, etc.).

If you can share the full file specification or a sample file, we can help recommend the best mapping approach. I'm aso adding in @Pranaw Sharma​, he's super knowledgeable in this area too if I'm away.

Just a Note: If the inbound file is a Sun Life XML where the data is stored as XML node attributes, it requires specialized XML processing that is not currently supported by the standard import types in Integration Studio.

Support for this type of XML handling is currently under development as part of the Integration Studio feature set. At this time, a prebuilt Sun Life template or out-of-the-box connector for this specific file format is not available.

Hi @Brenda Sutton​ ,

I wanted to follow up on my previous message regarding the Sun Life integration.

I explored the Pay Entry Import option for this integration; however, it does not fully meet the requirement. I was unable to find any out-of-the-box import type or prebuilt connector that supports the file layout provided by Sun Life.

I'm looking for confirmation on a behavior we're encountering with an Inbound File Integration (Build My Own) using a Delimited (Pipe|) File Source.

Source File Structure -

The incoming file contains multiple record types with different layouts:

• Header records (H) – 10 columns
• Detail records (D/E) – 14 columns
• Trailer records (T) – 9 columns

Row 1 - Header Indicator|File Sequence ID/Policy Number|Company ID|Payroll Spreadsheet Run Date|Company Name|File Type|Payroll Period From Date - To Date MMDDYYYY|Frequency Monthly/Biweekly|Record Count (including Header)|Member Count

Row 2 - H|103650|ABC|06042026|XYZ|Payroll Feed|05312026-06132026|Biweekly|101.51|2

Row 3- D|123456|06/14/2026|Test|Test|00|170|B|A|76.51|NULL|NULL|O

Row 4 - E|123456|06/14/2026|Test|Test|00|NULL|B|N|25.00|NULL|511|A

Row 5 - Trailer Indicator|File Sequence ID/Policy Number|Company ID|Payroll Spreadsheet Run Date|Company Name|File Type|Payroll Period From Date - To Date MMDDYYYY|Frequency Monthly/Biweekly|Premium Deduction Total

Row 6 - T|103650|ABC|06042026|XYZ|Payroll Feed|05312026-06132026|Biweekly|101.51

• Row 1: Header definition
• Row 2: Header values
• Rows 3-5: Detail records containing the actual deduction/earning data
• Row 5: Trailer definition
• Row 6: Trailer values

The file is delivered via SFTP and contains:

• A header section
• Detail records (D/E records) that need to be imported
• A trailer section

Our requirement is to process only the detail records (Rows 3 and 4) and ignore the first two rows (header information) as well as the last two rows (trailer information).

Issue Observed -

The file is being parsed based on the configured source structure before any IDL filtering can be applied. As a result, Integration Studio attempts to map header values to the detail schema and throws errors similar to:

InvalidMapperConfiguration: Unable to parse 'Company ID' as date (Field Name: Period End Date)

We have already tried filtering in IDL using logic similar to:

filter(source?.root?,

   r =>

       (r?.HeaderIndicator? ?? "") =~ "D" ||

       (r?.HeaderIndicator? ?? "") =~ "E"

)

However, the error appears to occur before the mapping/filtering phase.

Questions -

1. Can Dayforce Integration Studio (Build My Own – Inbound File) natively support mixed-layout CSV files where different record types (H, D/E, T) have different column counts and schemas, or are such files not supported and required to be preprocessed before ingestion?
2. Is it possible to ignore the header and trailer rows while importing only the detail records (D/E)?
3. If not through Pay Entry Import, is there another recommended inbound integration approach for handling this file format?

Any guidance or best practices from others who have implemented carrier payroll deduction imports would be greatly appreciated.

Thank you!

@Kanak Johari​  - I should have scrolled a bit more! The cleanest path is Build My Own (Inbound File), but I would not try to ingest the mixed H / D-E / T file as-is. Dayforce’s inbound file connector is for CSV, XML, or JSON files and then maps the raw source into a Dayforce-supported XML import file. The filtering tools in Integration Studio are applied in the mapping step against the source array, and Choose Record is meant to pick a specific record from an array, not to rescue a file whose rows already violate the declared structure. So my read is that a mixed-layout file like this should be preprocessed into a normalized detail-only file before ingestion.

For your exact use case, the practical design is: vendor file → lightweight split/filter step → pipe-delimited detail file only → Build My Own (Inbound File). That lets you drop the header and trailer rows upstream and keep Dayforce focused on one consistent schema.

If Sun Life cannot provide a detail-only extract, I would handle the split in middleware or a small script before Dayforce sees the file. In other words: Dayforce can be the importer, but it should not be the first parser for a file that changes shape by record type.  

I want to make sure answer your specific questions:

Q1: Can Dayforce Integration Studio (Build My Own – Inbound File) natively support mixed-layout CSV files where different record types (H, D/E, T) have different column counts and schemas, or are such files not supported and required to be preprocessed before ingestion?

A: No, not natively. The Build My Own (Inbound File) connector supports CSV, XML, and JSON sources, but it expects a consistent source structure. For mixed-layout files where H, D/E, and T records have different schemas, I would treat these as not supported as-is and recommend preprocessing the file into a consistent detail-only format before ingestion.

Q2: Is it possible to ignore the header and trailer rows while importing only the detail records (D/E)?

A: Not reliably in this scenario. Integration Studio filtering and Choose Record functionality operate after the source has been successfully parsed into its defined structure. If the parser encounters header or trailer rows that don't match the configured schema, the integration can fail before any filtering is applied. For this file layout, the header and trailer records should be removed upstream or the file should be split before Dayforce processes it.

Q3: If not through Pay Entry Import, is there another recommended inbound integration approach for handling this file format?

A: If Pay Entry Import doesn't meet the requirement, the recommended approach is still Build My Own (Inbound File), but with a preprocessing step to convert the mixed-layout file into a standardized detail-only file before ingestion. I don't see another out-of-the-box inbound connector that is designed specifically to consume this type of mixed-layout carrier file.  

Adding in @Pranaw Sharma​ to keep me honest here and provide any other thoughts I may have missed.