Skip to main content
Developer Communities Admin
Community Manager
September 15, 2026

I’m working on an Integration Studio inbound file for Employee Demographics, specifically for Work Assignment updates.

  • September 15, 2026
  • 37 replies
  • 30 views

Originally posted by Kanak Johari on May 27, 2026 at 1:12 AM.

 

Hi Everyone,

 

I’m working on an Integration Studio inbound file for Employee Demographics, specifically for Work Assignment updates.

 

In our inbound file, we receive values such as Jobxrefcode, Deptxrefcode, Orgxrefcode, Isprimary, and FTE. Our understanding is that when any of these attributes change, Dayforce creates a new Work Assignment record with a new effective start date.

 

However, we are observing a scenario where the effective date changes in the incoming full load file, but none of the actual work assignment attributes are modified. This happens because the source system includes additional work-assignment-related fields that change frequently, even though those fields are not maintained in Dayforce.

 

In this scenario, should Dayforce still create a new Work Assignment row solely because the effective date changed? Or is there a recommended approach to handle this so that no new Work Assignment row is created when there is no actual change in work assignment data, despite a different effective date?

 

Any guidance or best practices would be appreciated. Thank you!

    37 replies

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Lexi Woodward on Sept 30, 2026, 10:18 AM.

     

    Hi @Kanak Johari  Quick clarification: are you looking to understand how/when the HR Import updates an existing work assignment vs creating a new one regardless of how the import file is created, or how to configure a filter within an inbound integration to only include specific assignments? I can help with the IS configuration if you have the details, but unfortunately we'd have to loop in the folks who own the HR Import to advise on the logic there.

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Kanak Johari on Sept 30, 2026, 10:22 AM.

     

    Hi @Lexi Woodward​ , SORRY ! I think there is a bit confusion due to this loop. My recent posted question is below. Your guidance is greatly appreciated.

     

    I am configuring an Build my own (Inbound File) integration using Dayforce Pay Entry Import and am looking for suggestions on how to handle the deduction code dynamically based on an employee’s Pay Group.

     

    The vendor is not providing the employee’s Pay Group or Deduction Code, as they do not store or maintain this information in their system. Both the Pay Group and Deduction Code are specific to our Dayforce payroll configuration.

     

    Since Pay Group is not available in the inbound file, I am using: AutoDetectPayDataPayGroup = true to allow Dayforce to determine the appropriate Pay Group for the employee during the Pay Entry Import.

     

    The challenge is with PRDeductionXrefCode. We have different deduction codes depending on the employee’s Pay Group:

    Pay Group 100 -> Deduction Xref Code 5090

    Pay Group 200 -> Deduction Xref Code 5091

     

    Since the vendor does not maintain Pay Group or Dayforce Deduction Code information, they are unable to provide either value in the inbound file.

     

    My understanding is that AutoDetectPayDataPayGroup is a Boolean (true/false). Although Dayforce uses this setting to determine the employee’s Pay Group during the import, I am not sure whether the Pay Group identified by the auto-detection process can then be referenced within the IDL mapping to derive

    PRDeductionXrefCode.

     

    Looking for suggestions on the following:

    1. Is there a way to reference the Pay Group identified through AutoDetectPayDataPayGroup within the same Pay Entry Import/IDL mapping?
    2. Is there any other recommended Dayforce configuration or integration approach that would allow PRDeductionXrefCode to be determined based on the employee’s Pay Group?

     

    Our preference is to manage this logic within Dayforce, since the vendor does not store the employee’s Pay Group or Dayforce Deduction Code and therefore cannot provide these values in the inbound file.

     

    Any suggestions or alternative approaches would be greatly appreciated. Thanks !

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Lexi Woodward on Sept 30, 2026, 10:28 AM.

     

    No worries! You guys have chatted a lot and I responded to the item in email without reading through the chain on the community. I have learned my lesson, haha.

     

    Unfortunately, the AutoDetectPayGroup is a boolean value that lets Dayforce derive the pay group during the import processing, but holds no meaningful information for deriving the deduction code name when creating the import file in Integration Studio. We’d need something in the source that could be used to derive that value, even if it is as simple as a single character which correlates to a pay group.

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Kanak Johari on Sept 30, 2026, 10:45 AM.

     

    Hi @Lexi Woodward , Thank you so much for the quick response! That aligns with my understanding as well based on the testing I’ve done. I’ll take this forward accordingly and explore what information we can have included in the source file to derive the appropriate deduction code.

     

    I have one more question regarding Integration Studio. When I select the “Build My Own (Inbound File)” connector, we’re required to select an Import Type. However, I don’t see Quick Entry Import available as one of the Import Type options.

     

    Could you please confirm if Quick Entry Import is intended to remain a manual Payroll import process and is therefore not supported through Integration Studio, or if there are plans to add it as an available Integration Studio Import Type in the future?

     

    Developer Communities Admin
    Community Manager
    September 30, 2026

     

    Originally replied by Lexi Woodward on Sept 30, 2026, 10:53 AM.

     

    You're very welcome!

     

    Quick Entries are currently importable one of two ways:

    1. Directly in the Payroll module (I believe this is the manual option you're referring to)
    2. Using the Payroll Import feature

    We do not have definitive plans to support quick entry import through Integration Studio at this time, but as we work towards exposing more payroll functionality in Integration Studio, this is something we can consider. If this is a common requirement that you come across, please add an idea in the Aha! Portal for our consideration.

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Kanak Johari on Sept 30, 2026, 1:12 PM.

     

    Hi @Lexi Woodward​ , Thank you again for your help! I have one more unique requirement that I was hoping to get your guidance on.

     

    This is a Build My Own (Outbound File) integration, and I’m leveraging a custom report to generate the outbound file and pass the required data to the vendor.

     

    The requirement is a little unique, so I wanted to check with you on the best way to achieve it through the custom report or either via Build my own (Outbound File). Please see the scenario below.

     

    It is a vendor Manulife - Basically, for one policy, we have 6 deduction codes (include Deduction code as 100, 112, 114,110, 111, 113) associated with it. The vendor wants these 6 codes to be further split into two groups:

    • 3 deduction codes are tied to the Employee contribution
    • 3 deduction codes are tied to the Spousal contribution

    However, both Employee and Spousal amounts need to be reported under one policy number column only.

     

    Currently, I’m able to sum all 6 deduction codes together and generate the total amount in a single row.

     

    The requirement, however, is to split that total into two separate rows based on the deduction codes.

     

    For example, if Employee 12345 contributes:

    • Total of $100 toward their own RRSP (include Deduction code as 100, 112, 114)
    • Total of $50 toward the Spousal RRSP (include Deduction code as 110, 111, 113)

    The expected output would be:

     

    imageHere Member Number = Employee Number/Employee ID

     

    So, the first 3 deduction codes should be summed and reported against the employee's regular Member Number, while the other 3 Spousal deduction codes should be summed separately and reported as another row with an "S" appended/suffix to the Member Number.

     

    I’m trying to understand how I can achieve this row-level split within the custom report.

     

    Do you have any suggestions on how this could be achieved either via custom report itself or either via Integration Studio (Outbound file). Any guidance would be really appreciated!

    Developer Communities Admin
    Community Manager
    September 30, 2026

    Originally replied by Lexi Woodward on Sept 30, 2026, 1:29 PM.

     

    Unfortunately I'm not able to advise how to do this in the custom report, however this sounds like it could fit fairly well into two of the 10 design patterns we recently documented and added to the Integration Studio Admin Guide.

     

    To move from one row per employee with all deduction codes summed to one row per employee + set of valid deduction codes, you would need to look at grouping and possibly linked maps. I would take a peek at the "Simple Group on Flat Data" and "Data Roll Up" design patterns to get started. These patterns assume a flat source data set (as we see in a Dayforce Report) and that the output needs to be rolled up/grouped by one or more values. You may not need multiple maps for the grouping, but I can see a world where you would need:

    • Map 1: Map required employee fields, including one or more fields which create a unique employee identifier, and create a new field, ex: DeductionIdentifier, which can be used as a grouping key based on the deduction codes using conditional mapping. For ex:
      • Criteria Set 1: DeductionCode = 100, Output "EE Cost"
      • Criteria Set 2: Deduction Code = 112, Output "EE Cost"
      • Criteria Set 3: DeductionCode = 114, Output "EE Cost"
      • Else: "Spouse Cost"
    • Map 2: Group the data by Employee identifier and new deduction identifier value. Once grouping is applied, sums will be calculated per group (i.e. per unique combination of employee identifier and deduction identifier)
      • Presumably the deduction identifier needn't be included in the output. If so, you can use the "exclude grouping key from output" option from the Action menu on the grouping key data field