Enhance Benefits Connectors
Overview
This chapter explores advanced concepts for end-to-end connectors in any functional area, including integration security, calculated fields, and change detection.
Objectives
By the end of this chapter, you will be able to:
- Validate that the necessary data exists in the tenant before testing.
- Configure integration security for an end-to-end connector.
- Create calculated fields to capture specific information.
- Create and run a custom report to validate calculated field values.
- Configure an end-to-end connector to use change detection.
- Configure CCB launch parameters for full file, change file, and open enrollment files.
Integration Data and Security
End-to-end connectors use simpler integration security practices than most custom connectors. Workday recommends you configure an integration system security group (ISSG) for each integration product area, like Payroll or Benefits, and an integration system user (ISU) for every integration system. The ISSG should have security access to the necessary integration data and administration domains for that product area.
Validate your integration security configuration by running an end-to-end connector integration in that product area, then examining the output file for excluded data. You can use functional reports to identify if data is missing because it does not exist in Workday, or because the ISU has insufficient security.
Example
: Create an ISSG and ISU for a CCB, then launch it. Consult benefits reports, like View Current Benefit Elections
, to see if the integration output file includes all data.Capturing Required Data
Often, to meet customer or provider formatting and data requirements, you will need to use more advanced configuration than integration maps.
Example
: The provider requests that the element representing birth date uses a different format than the default. Integration maps and integration field overrides alone cannot meet this request.Calculated Fields
Use calculated fields to combine, format, pull, and remove Workday data so it appears correctly in an integration system's output file. Some common calculated fields used with end-to-end connectors include:
- Build Date
- Concatenate Text
- Date Constant
- Evaluate Expression
- Format Date
- Format Number
- Format Text
- Substring Text
- Text Constant
- True/False Condition
Resource
: For more information on all available calculated field functions, view the Administrator Guide. Search Reference: Calculated Field Functions
Naming Conventions
While configuring end-to-end connector integrations, you will likely create dozens of calculated fields. To manage the fields, establish or follow naming conventions that describe the calculated field so you can easily find and understand it.
View Calculation Hierarchy
Often, you will configure calculated fields with several nested calculated and report fields.
Example
: To correctly populate dates in the output file, you need to create an evaluate expression that contains several true/false conditions, several concatenate text fields, and numerous substring text fields.To easily identify how calculated fields relate, locate the top-level calculated field. From the field's Related Actions, select Calculated Field, then View Calculation Hierarchy. The folder and document structure reveals how different calculated fields and report fields relate to one another.
Field Overrides
Once you create your calculated fields, identify the correct integration field overrides to use them with. Remember, integration field overrides only accept one field value. If you want to return different values for different conditions, you need to use evaluate expression fields or other conditional calculated fields. These calculated field functions can synthesize multiple logical expressions and values into one field that you can use as the field override.
Generally, using complex calculated fields with field overrides increases an integration event's processing time. Therefore, design your calculated fields to use as few fields and conditions as possible, increasing processing efficiency. Also, keep maintenance in mind when creating calculated fields, as you may need to add or modify the fields throughout the design and testing process.
Custom Reports
While you can validate calculated fields in an integration output file, you can also build a custom report in Workday. Include your calculated fields in the report, along with the report fields they use, to confirm if they pull the correct data for different workers or records. Additionally, you can verify the calculated field formatting.
Example
: If you create an evaluate expression field, include that field and all the fields nested inside of it, like substring text fields and true/false conditions, in a report. Ensure that the report data source will populate the same data as the integration system you created calculated fields for. Run the report to validate the calculated field structure.Change Detection
Change detection differs slightly given the end-to-end connector integration template, but the templates all use similar logic.
Generally, change detection looks for data that is either newly entered or newly effective.
- Newly effective: Data with an effective date in the specified effective date range.
- Newly entered: Data entered in Workday during the specified update range with an effective date on or before the end of the effective date range.
Reminder
: For CCBs and several other end-to-end connector templates, the template preconfigures the transaction log. While you can review the transaction log, you should not modify its configuration.Launch Parameters
Different end-to-end connector templates offer different date and time launch parameters. Consider the common launch parameters in the context of CCBs below.
Launch Parameter | Purpose |
|---|---|
Effective Date | When enrollments are first valid. This is the start date for the newly effective date range. |
From Effective Date | When enrollments are most recently valid, defaults to the current date. This is the end date for the newly effective date range. |
Last Update | When the integration event launches, often the default current date and time. This is the start date for the newly entered date range. |
From Last Update Date | When the integration event last launched, often the default one hour prior to current date and time. This is the end date for the newly entered date range. |
Payroll Start Date | When the integration event last launched and collected payroll data. |
Payroll End Date | When the integration event launches and collects payroll data, often the default current date and time. |
Note
: For end-to-end connectors that use payroll data, note that filtering by an organization may exclude terminated workers from the output. Since the worker is no longer a member of the organization, the output file does not include them, even if the integration should detect their termination.CCBs report eligibility and enrollment activity based on the benefit plan year of the Effective Date launch parameter. Benefit plans have a new coverage start date at the beginning of each new plan year. To report end of year coverage end dates, the Effective Date launch parameter must be equal to or before the last day of the benefit plan year.
Resource
: For more information, search for the Launch Parameters and Filtering CCB Output page in Workday Community.Scenarios
Consider the following scenarios and corresponding launch parameter configurations.
Scenario | Effective Date | Last Update | From Effective Date | From Last Update |
|---|---|---|---|---|
The endpoint wants a full file snapshot of the current data in Workday. | Current Effective Date | Current Moment (DateTime) | ||
The endpoint wants all new changes, but not changes previously reported. | Current Effective Date | Current Moment (DateTime) | As Of Effective Date of Last Completed Integration Event | As Of Entry DateTime of Last Completed Integration Event |
The endpoint is a benefits provider requiring an open enrollment file. | (First day of the new plan year, often January 1) | Current Moment (DateTime) | (First day of the new plan year, often January 1) | Current Moment (DateTime) |
Change Detection Scenarios
Consider these change detection scenarios for CCBs.
Scenario | Today's Date | Event Entry | Event Effective Date | Last Integration Run | Integration LP's | Result |
|---|---|---|---|---|---|---|
Currently effective change: Paul Black is terminated. | 06/19 | 06/19 12:00PM | 06/19 | 06/13 7:00AM | From Effective Date: 06/13 Effective Date: 06/20 | The event effective date and entry date are the same, so this change is newly effective. The output file includes Paul's termination. |
Retroactively effective change: Paul Black is terminated retroactively. | 06/19 | 06/19 12:00PM | 06/05 | 06/13 7:00AM | From Effective Date: 06/13 Effective Date: 06/20 From Last Update: 06/13 7:00AM Last Update: 06/20 7:00AM | The event entry date is after the last integration run date and the From Last Update launch parameter. The event effective date is before the From Effective Date launch parameter, so this change is newly entered and already effective. The output file includes Paul's termination. |
Future effective change: Paul Black is terminated in Workday with a future effective date. | 06/19 | 06/12 12:00PM | 06/18 | 06/13 7:00AM | From Effective Date: 06/13 Effective Date: 06/20 | The event entry date is before the last integration run, but the event effective date is after. The last integration did not include it, and the event effective date is after the From Effective Date parameter, so this change is newly effective. The output file includes Paul's termination. |