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

Originally replied by Brenda Sutton on May 28, 2026, 5:43 PM.

Hi @Kanak Johari​, your instinct is correct. In most cases, Dayforce should only create a new Work Assignment row when a meaningful assignment attribute changes (Job, Dept, Org, FTE, Primary flag, etc.), not just because the incoming effective date changed.

If the source system sends full-load files and the effective date changes due to non-Dayforce fields changing upstream, the recommended approach is usually to suppress the Work Assignment update unless one of the mapped Dayforce assignment attributes actually changed.

Otherwise, you can end up with unnecessary effective-dated Work Assignment history and unintended downstream impacts (events, payroll, reporting, integrations, etc.).

Typical approach:

• Compare incoming values vs current Dayforce values
• Only generate the Work Assignment import row if a mapped assignment field changed
• Ignore date-only changes caused by source-system-only fields

This keeps Work Assignment history cleaner and avoids “false” historical changes.

Originally replied by Kanak Johari on May 29, 2026, 12:48 AM.

Hi @Brenda Sutton​ , Thank you for your insight and guidance. Your explanation really helped clarify the expected behavior for Work Assignment updates. I have a few follow-up questions regarding how to implement this in Dayforce Integration Studio.

I created a “Create My Own Inbound File” integration and used the HR Import autofill mapping option, which created separate arrays for Basic Employee Info, Work Assignment, Employment Status, and Address. In the Work Assignment array, I currently do not see any option that says like compares records received from the previous day/file.

In this scenario, what would be the recommended approach in Integration Studio?  Should I:

• build some logic/expression inside the Work Assignment effective date field,
• apply logic at the Work Assignment array level to suppress unnecessary rows,
• or ideally ask the vendor/source system to only send records when there is a real change in mapped Work Assignment attributes (Job, Dept, Org, FTE, etc.) and not just an effective date change?

I am currently testing in the Stage environment on release version 2026.1.1.1.1

I also had another question regarding PGP configuration for inbound files. The client mentioned that for inbound integrations I need to generate both private and public PGP keys, and only the public PGP key should be shared with the vendor. I understand that the private PGP key is generated/configured inside Integration Studio, but where exactly do we configure or manage the public PGP key in Dayforce?

Could you also please guide me on the additional steps required to configure or build the WA logic as well as the inbound encrypted file setup properly in Dayforce Integration Studio?

Thanks again for your help!

Originally replied by Brenda Sutton on May 29, 2026, 10:45 AM.

Hi @Kanak Johari​ , one small adjustment to the previous answer. Integration Studio inbound file integrations do not have native "compare against yesterday's file" functionality, so the platform itself isn't maintaining a history of prior inbound records that you can easily compare against in a mapping. Based on your screenshot, I would avoid putting the logic on the EffectiveStart field itself. If the WorkAssignment segment is still generated, Dayforce may still process it as a Work Assignment update.

If you want to suppress unnecessary updates, the WorkAssignment parent/array level would be the more appropriate place to apply filtering so the entire segment can be omitted.

The bigger challenge is that Integration Studio only sees the current inbound record. It doesn't natively compare against yesterday's file or existing Dayforce Work Assignment values unless you provide another comparison source.

Because of that, the preferred approach is usually to have the source/vendor send only true Work Assignment changes (Job, Dept, Org, FTE, Primary Flag, etc.). Otherwise, you would need an additional comparison source to determine whether the incoming record actually represents a change.

For the SFTP - For inbound integrations, the vendor only needs your public PGP key so they can encrypt the file before sending it to Dayforce. Dayforce then uses the corresponding private PGP key to decrypt the inbound file during processing.

In Integration Studio, the private key is configured on the inbound integration itself. Specifically, for the Build My Own (Inbound File) connector, the source configuration includes fields for:

• Private PGP Key
• Passphrase

These are used by Integration Studio to decrypt the incoming file before mapping and processing it.

Where is the public key configured?

It generally isn't configured separately in Integration Studio.

The public key is simply the public half of the same key pair that corresponds to the private key you upload/configure. You provide that public key file (

.asc

or

.pgp

) to the vendor, and they use it for encryption.

Typical process

1. Generate a PGP key pair:

• • Private Key
  • Public Key

1. Configure the Private Key + Passphrase in the inbound Integration Studio configuration.
2. Send the Public Key to the vendor.
3. Vendor encrypts files using your public key.
4. Dayforce decrypts the file using the configured private key.

Practical Dayforce consideration

Integration Studio documentation only references configuring the Private PGP Key and Passphrase for inbound file decryption; it does not provide a separate UI location for managing or storing the public key.

So if the client is asking "where do I configure the public key in Dayforce?", the answer is usually:

You don't configure the public key in Integration Studio. The public key is generated from the same key pair as the private key, shared externally with the vendor, and only the private key/passphrase are configured in the inbound integration.

One thing I'd clarify with the client: who is expected to generate the key pair? Some implementations have the customer generate the key pair externally (GPG, Kleopatra, etc.) and provide the public key to the vendor, while others may have an existing enterprise key-management process. That determines where the public key actually originates.

Originally replied by Kanak Johari on May 29, 2026, 12:20 PM.

Hi @Brenda Sutton​ , thank you again for all the clarification — it was really helpful. I had one additional question regarding inbound HR Imports and Integration Studio behavior.

Is it feasible for Integration Studio inbound processing to compare incoming Work Assignment records against the existing values already stored in Dayforce and suppress the update if the data is unchanged?

For example, if the inbound file sends a new effective-dated Work Assignment row with identical Job/Dept/FTE values, is there any native capability within Integration Studio to prevent Dayforce from creating or processing the update simply because the effective date changed? If yes, then how to approach it or how to configure it.

Also, while using the HR Import in the inbound integration, I noticed that the import schema appears to be very strict regarding supported XML elements. I attempted to include fields such as OriginalHireDate and FirstDateWorked in the Employee node, but the import failed validation with an “invalid child element” error.

Is it correct to say that HR Import only supports the fields explicitly defined in the Dayforce HR Import schema, and additional/custom elements cannot be added to the mapping unless they are supported by that specific import? If these fields are needed, what would be the recommended?

Thanks again for your help.

Originally replied by Brenda Sutton on May 29, 2026, 12:45 PM.

@Kanak Johari​ , whoops, missed that! No, IS currently doesn't have the ability. The requirement, however, has already been submitted by my team as an enhancement due to additional use cases that we've encountered. No specific timeline for the enhancement has been published yet.

Originally replied by Kanak Johari on May 30, 2026, 10:41 AM.

Hi @Brenda Sutton​  Thank you so much for your guidance !

Originally replied by Kanak Johari on Jun 2, 2026, 12:22 PM.

Hi @Brenda Sutton​ , Hope you are doing well. I’m working on an Integration Studio inbound file for Employee Demographics. I wanted to check the feasibility for the requirement related to Display on Tax Statement and Display on Earnings Statement in Dayforce before proceeding with configuration.

Requirement Overview

The client’s expectation is based on address type (Primary Residence and Mailing) as follows:

• • If only Primary Residence exists:Tax Statement = True
  • Earnings Statement = True
  • If only Mailing exists:Tax Statement = True
  • Earnings Statement = True
  • If both Primary Residence and Mailing exist: Mailing address → Tax Statement = True
  • Primary Residence → Earnings Statement = True

Additionally, when a Mailing address is introduced after a Primary Residence already exists, the system should automatically adjust so that:

• Tax Statement is updated to Mailing
• Primary Residence is no longer used for Tax Statement
• Earnings Statement remains tied to Primary Residence

Note: The client is not providing “Display on Tax Statement” or “Display on Earnings Statement” fields in the source file. They expect Dayforce to determine this logic during processing.

Feasibility Question

Before proceeding further, could you please confirm:

1. Is this type of dynamic selection / override logic between address types feasible within Dayforce Integration Studio using IDL expressions or conditional mapping alone?
2. Or does this requirement require a different design approach ?

Additional Observation

During testing, I also noticed that when sending two separate rows for the same employee (Primary and Mailing) in the inbound file, the integration throws an error related to XRefCode as "ERROR: Path is ambiguous at \"root\"\n>>> XRefCode = ((source?.root?.EMPL_XREF? ?? nil) ?? nil);"

This raises a question regarding the intended design:

• Is the inbound file doesn't support multiple address records per employee in a single feed/file?
• If yes, how should we handle the XRefCode constraint when multiple address types exist for the same employee?
• Or is the intended approach to process one address record at a time per employee in a single feed/file ?

Could you please confirm the recommended design approach so I can align the configuration accordingly?

Originally replied by Brenda Sutton on Jun 2, 2026, 2:00 PM.

@Kanak Johari​ , Thanks for the details. Based on my review, the business requirement appears feasible, but I don't believe it can be achieved through conditional mapping alone when multiple address records exist for the same employee. Integration Studio treats addresses as an array, so the appropriate address record (Primary Residence vs. Mailing) would need to be explicitly selected using Choose Record logic or a source/data structure that resolves the address instance before applying the statement flags.

The "Path is ambiguous" error you're seeing on XRefCode is typically an indication that the integration is attempting to reference a field from a source array that contains multiple records without first narrowing the result to a single instance. This would align with the scenario where both Primary Residence and Mailing records are being provided for the same employee.

Given the nuances around Employee Demographics imports and address processing behavior, I'm engaging our Integration Studio SME's @Shruti Srinivasan​ and @Lexi Woodward​ to confirm the intended design pattern and any Dayforce import-specific behavior around the Display on Tax Statement and Display on Earnings Statement fields.

Thanks,

Brenda

Originally replied by Shruti Srinivasan on Jun 2, 2026, 3:38 PM.

If your source data has multiple separate rows for the same employee, but your logic needs to look at the combination of data in both, then you will need to group both rows into one employee record so that you can set up conditional mappings using data on the same record. I would suggest using multiple mapping steps: the first mapping to group all the rows for the same employee, and then the second mapping to apply conditional logic and transformations on the grouped record. You can find more information and examples in the Help documentation, eg https://help.dayforce.com/r/documents/Dayforce-Integration-Studio-Administrator-Guide/Change-the-Structure-of-Your-Data

Originally replied by Lexi Woodward on Jun 4, 2026, 3:51 PM.

Hi Kanak, there's a few nuances to this situation:

1. The need to group records - when multiple records exist for the sample employee in the source, grouping is required to ensure we consider each employee holistically/to avoid the 'Path is Ambiguous' error. It sounds like we've successfully managed this nuance.
2. The need to conditionally map TRUE or FALSE to the Tax Statement and Earning Statement flags - based on the logic provided, this should be possible using conditional mapping for each field. If the employees could have multiple addresses, you would need to consider each address type independently in the Conditional Mapping configuration by way of Choose Record. In other words, each criteria set should test for a specific scenario, in the order you want the records to be evaluated. For example, the first criteria set could test for whether the PrimaryResidence address exists. This could look like:

1. The need to associate a specific address with the Tax Statement/Earning Statement - I'm not quite clear on this requirement. Can you expand which fields in the HR Import you are trying to map to and what value you are trying to map to that field?

I'm not seeing a reason you would need an expression to meet this requirement, but please let us know if we missed anything.