Sickness Period Management

Note: This integration is an extension that is developed outside the normal release schedule to meet specific customer needs. To request one of these extensions, you must submit a Salesforce Service Request to UKG. After the extension is delivered to your tenant, you can edit it accordingly.

The Sickness Period Management integration extension automates the process of dividing an employee's sickness period into waiting, paid sick, and unpaid sick leave periods, with corresponding cascading duration paycode assignments.

This integration extension offers the following:

Sickness period evaluation

After the user enters a sickness placeholder paycode identifying the entire sickness period, the extension evaluates the waiting, unpaid, and paid sick leave periods. It then cascades through a series of duration paycodes, adding the appropriate duration paycode next to the placeholder paycode in the timecard. Hours from the duration paycodes are calculated, and then exported to payroll.

Note that the cascade must be configured with duration paycodes so that shift premiums can be calculated during periods when sickness pay is applied.

Paycode visualization

The extension inserts duration sickness paycodes around scheduled break segments in the timecard. By inserting as many sickness paycode segments as there are segments in the shift, it ensures that the duration reflects regular and transfer segments in the shift.

Waiting period

Organizations can enable waiting periods in the extension. When enabled, the first part of the sickness period is considered unpaid. The number of times that the waiting period can be applied is configurable; for example, a maximum of 10 times in the 12 months prior to the relevant sickness period.

Two methods are available to determine the waiting period:

  • Number of calendar days — A specified value, representing the number of unpaid days. For example, 1.

  • Percentage of weekly contract hours — A calculated value, that uses the Employee Hours in People Information, to determine the number of unpaid hours. For example, when Employee Hours = 40 and the percentage of weekly contract hours = 20, the employee’s waiting period is calculated as 8 hours.

With the percentage of weekly contract hours method, the waiting period could span multiple days. When hours in first shift of the sickness period do not sufficiently cover the waiting period, the extension searches for the next shift, skipping unscheduled days, until the waiting period hours are satisfied.

Relapse

A relapse occurs when an employee calls out sick, within a predefined amount of time, after returning from a sickness period. The extension identifies the relapse and continues the previous sick period without starting new waiting and sickness periods.

Note that the paid sick period continues only until the point at which the previous sick period plus the relapse period equals a set maximum number of calendar days.

Sickness and premium zones

As part of an employee’s guaranteed salary, sick leave taken during a shift that would otherwise have earned a shift premium when worked, also merits a shift premium. The extension uses duration paycodes, which allows flexibility when applying the necessary premiums.

The following sickness policy applies to each user scenario:

  • An unpaid waiting period of 20% of the employee’s weekly contract hours, represented by a paycode named Waiting Period.

  • A paid sickness period applies to the first 14 calendar days, and is represented by a paycode named Partial Sick First 14 days.

  • Sick Long-Term begins on the 15th calendar day.

  • Paid sickness earns a shift premium, but at a lower premium than when worked.

  • A 5-day relapse period.

  • Only 10 waiting period occurrences can be applied in the 12 months prior to the relevant sickness period.

Different sickness periods

A full-time employee, with a 40-hour contract, alternates between working day shifts and late-plus-weekend shifts, earning a shift premium.

The employee starts the late Monday shift, but then leaves before the second part of the shift begins. When the employee, who will be out sick for the next 3 weeks, notifies the manager, the sickness period is entered in UKG Pro Workforce Management™.

  • The first 8 hours, which span from the second part of the Monday shift through the first half of the next scheduled shift, are considered the 20% unpaid waiting period.

  • Even though the employee is scheduled for the late shift on Monday, no shift premium is earned during the waiting period hours. The employee does, however, earn shift premiums for the late shifts scheduled through the 14th calendar day.

  • Beginning on the 15th day, the remaining sickness period is treated as Sick Long-Term, and does not earn a shift premium.

Relapse and sickness continuation

A part-time employee, with a 32-hour contract (8-6-6-6-6), is sick for the first 3 days of the first work week.

  • The extension evaluates the first shift, replacing it with paycodes for Waiting Period (6:24), and Partial Sick First 14 days (1:16).

  • Scheduled shifts on days 2 and 3 are replaced with Partial Sick First 14 days (6:00).

The employee returns to work on the fourth day of the schedule, but then relapses on the fifth day; the employee's absence continues through the second day of the second week's schedule.

  • The extension considers the sickness period a relapse, since it occurs within 5 calendar days of the previous sickness.

  • No waiting period is necessary, and the count of the first 14-day paid sick continues for a total count of 8 days.

On the first day of work week three, the employee is sick again.

  • The extension considers the sickness period as new, since this occurrence is 6 calendar days after the previous sickness period.

  • A new sickness period begins with a new waiting period.

Waiting period limitation

A part-time employee with a 20-hour contract (4-4-4-4-4), who has already been sick 9 times in the previous 12 months, is sick the entire week.

  • The first 4 hours are considered the 20% unpaid waiting period.

  • The remaining shifts occur within the 14-day paid sickness period, and are replaced with Partial Sick First 14 days (4:00).

Two weeks later, the employee is sick again.

  • The extension considers the sickness period as new, since its occurrence is outside the relapse period.

  • The extension evaluates the previous rolling 12 months and recognizes that, because 10 waiting periods have already occurred, no waiting period applies to this sickness period.

Before you configure this integration, you must do the following:

  1. Configure Access to Integrations.
  2. Configure the following:
  • Function Access Profiles (FAP): Edit the FAP assigned to any manager who runs the integration to allow Retrieve hidden pay code edits via API. See the Function Access Profiles topic.
  • Paycodes: Configure paycodes dedicated to integration processing. See the Paycode definition topic.

Examples include:

  • Sickness Placeholder — Applied on days that the integration processes as leave.

    • Type = Standard or Duration, Unit = Hour

Note: There is no requirement to assign a work rule to the duration-based paycode.
  • Applied Paycode — When required, assigns a work rule with a pay code distribution configuration.

  • Type = Duration, Unit = Hour

  • Day Count Paycode — (Optional) Applied in the timecard as a sickness count paycode.

  • Type = Standard, Unit = Day

  • Comments: Configure comments that are assigned to integration parameters. The paycodes category must be selected during configuration. See the Comments topic.

Examples include:

Comment for Sickness FirstDayIdentifier — (Required) Used in the timecard to identify the first day of the previous sickness period. Also used for the waiting period occurrence count.

Paycode Comment — (Optional) Applied to the timecard with the Applied Paycode.

  1. Get the URL, User, and Password for the APIGatewayServer.

  • When the value of Waiting Period in the _SicknessPolicy_CRT is Weekly Hours %, Employee Hours must be configured in the Full-Time Equivalency section of People Information. This value is used in the weekly hour amount calculation for the waiting hours.

  • Start and end times for duration paycodes are calculated based on the start time and amount entered for the sickness placeholder paycode. Scheduled and shift amounts are not used.

  • After the timecard is signed off, you must enable edits to modify any timecard data entered before sign-off. Timecard modifications performed after removing sign-off are not considered by the integration.

  • If sickness placeholder paycodes are entered in the timecard without a start time and amount, the integration disqualifies the employee from automatic sick leave calculation.

  • When adding comments and paycodes to the SicknessPolicy_CRT, SicknessRuleSets_CRTor as integration parameters, use the translated values associated with the tenant default locale policy.

Version Description
1

Initial release.
1.1 Added support for different locale policies configured for the tenant and the integration user.
2

Addressed an issue to now count sickness on unscheduled days.

Enhanced to support:

  • Partial day sickness paycode for the first 14 days of sickness.

  • The use of a duration paycode as a sickness placeholder paycode.

  • The ability to hide secondary paycodes from the main view in the timecard.

  • Employees who have been sick in excess of 366 days.
iPack_v3 The Sickness Period Management integration delivery is now by way of an iPack.

Deploy the Sickness Period Management integration

For more information, see the Deploy Integrations topic.

  1. Open the Integration Template Designer: Select Main Menu  > Administration > Application Setup > Integrations Setup > Design Integration Templates.

    Note: If prompted, enter your Username and Password. Click Tap Log in.

  2. Make sure that the Account is correct. If not, select the right account.

  3. Select the Deploy tab > Integration Packs.
  1. From the list in the left column, search for and select the Pro WFM Sickness Period Management Extension integration.

  1. From Unattached Environments, select the environment in which to deploy the integration process for the selected integration. Click Tap the double-left arrows button Select items.

Configure the Sickness Period Management integration settings

Select the environment

  1. Select the Manage tab > Atom Management.
  2. Select your environment.

Select environment extensions

  1. In Administration, click tap Environment Extensions.
  2. In Process Filter, click tap the magnifying glass Search button. It can take several seconds before the button becomes active.
  1. Scroll to and select the integration pack: Sickness Period Management > SicknessPeriodManagement_iPack_v3.

Configure connection settings

Caution: If you select Use Default for the connection settings and process properties, ensure that Value is blank. If Value is not blank, that value overrides the default value whether or not Use Default is selected or cleared. Example: If the default value is abc, but Value shows xyz, the integration uses xyz regardless of the setting of Use Default.

  1. Select Connection Settings.

  2. From the Connection list, select and configure the following:

    Connection Settings
    Setting Required Actions
    SicknessPeriodManagement_iPack_v3_APIGatewayServer Required

    To change the default API gateway server:

    1. Clear Use Default.
    2. Enter the URL to the server.

      Example: <tenantURL>/api
    SicknessPeriodManagement_iPack_v3_SicknessPolicy_CRT Required Enable Override.
    SicknessPeriodManagement_iPack_v3_SicknessRuleSets_CRT Required Enable Override.
    SicknessPeriodManagement_iPack_v3_Locale_CRT Required Enable Override.

Configure process properties

  1. Select Process Properties.

    Caution: Do not edit the default values of the AuthenticationProperties. By default, cookies are enabled and set the values for authentication properties.

  2. Select SicknessPeriodManagement_iPack_v3 to set process properties that must be configured before the integration can run. This main process starts the integration process and handles errors.

Process properties
Process property name Column header value
_SicknessPeriodManagement_iPack_v3_SicknessPolicy_CRT Pay Rule Name,Location,Version,Effective Start Date,Sickness Rule Set Name,Relapse Period,Sickness Occurrences Lookback,Maximum Sickness Occurrences,Waiting Period,Waiting Period Value,Sickness Count Paycode,Sickness Placeholder Pay Code
_SicknessPeriodManagement_iPack_v3_SicknessRuleSets_CRT Sickness Rule Set Name,Steps,Day Range,Applied Pay Code
_SicknessPeriodManagement_iPack_v3_Locale_CRT Parameter Name, Locale Policy, Value, Description

Configure cross-reference tables

Cross-reference tables (CRT) are the look-up tables that the integrations use to translate parameter values. One or more data values from the source system can be used to assign one or more parameters in the destination system.

  • If more than one row matches a reference value, the first match is the output value.
  • If no match is found, the output value can be null, or the integration can produce errors.
  1. Select Cross Reference.

  2. From the Cross Reference dropdown list, select the SicknessPeriodManagement_iPack_v3_Locale_CRT table.

  3. Select Override, which allows you to:

  • Download the table when you run the integration
  • Edit the table cells in Extensions
  1. When you finish, click tap OK.

Repeat the steps for each of the Sickness Period Management tables.

SicknessPeriodManagement_iPack_v3_SicknessPolicy_CRT: Stores configuration parameters of the different sickness policies.

Sickness Period Management — Sickness Policy CRT structure
Column name Description
Pay Rule Name

Identifies the pay rule to which the sickness policy applies.

References the employee's pay rule in effect on the sickness day.

The value must be configured in UKG Pro Workforce Management™.

Supports wildcards.

You can use an asterisk (*) as a wildcard, but put the less-restrictive locations at the bottom of the table because the integration scans cross-reference tables from the top.
Location

Identifies the location to which the sickness policy applies.

References the employee's primary location and job.

The value must be configured in UKG Pro Workforce Management™.

Supports wildcards.

You can use an asterisk (*) as a wildcard, but put the less-restrictive locations at the bottom of the table because the integration scans cross-reference tables from the top.
Version

Allows configuration of effective-dated sickness policies to accommodate changes.

Supports sequential numbers beginning with 1; must not exceed 10.
Effective Start Date

Effective start date (dd-mm-yyyy) for this version of the sickness policy.
Sickness Rule Set Name Sickness policy name. Referenced by the Sickness Rule Sets CRT.
Relapse Period The number of calendar days during which a newly entered sickness will be considered a relapse of the previous sickness.
Sickness Occurrences Lookback

The numbers of months before the relevant sickness that are searched for other sickness occurrences.

Works in conjunction with Maximum Sickness Occurrences.
Maximum Sickness Occurrences

The maximum number of waiting periods that can be applied.

Waiting period will not be applied when it is beyond this limit.
Waiting Period

The only supported value is Weekly Hours %; this entry is case-insensitive.
Waiting Period Value

The percentage, or fixed number of days, that determine the waiting period.

Entered as an integer.
Sickness Count Pay Code

Tracking paycode for the number of sickness days. A day-type paycode must be entered.
Sickness Placeholder Pay Code

Hourly or duration-type paycode used to add the sickness in UKG Pro Workforce Management™.

Note:

(Optional) Enter a wildcard (*) in the Pay Rule Name and Location columns of the last row in the table as the default selection when the employee's pay rule and location do not exist in the CRT.

SicknessPeriodManagement_iPack_v3_SicknessRuleSets_CRT: Stores the steps and applicable paycode for the sickness rule sets.

Sickness Period Management — Sickness Rule Sets CRT structure
Column name Description
Sickness Rule Set Name

Sickness Rule Set name as specified in the Sickness Policy CRT.

The name is used to link the rule set with the policy for each employee group.

The value is case-sensitive and must match the value in the Sickness Policy CRT.

Steps

Defines the steps into which a sickness period can be divided.

Supports sequential numbers beginning with 1; must not exceed 10.
Day Range

The range of calendar days associated with each step, such as 01-01, 02-14, and 15-999.

Minimum value = 1.

Maximum value = 999.

Step 1 must equal 01-01 or 1-1.
Applied Pay Code

The sickness paycode used when the rule step qualifies.

When necessary, add two paycodes separated by a semicolon (;).

The second paycode is used when a partial absence applies, such as when sickness is combined with worked time.

SicknessPeriodManagement_iPack_v3_Locale_CRT: Allows translation of messages and labels into different languages.

Sickness Period Management — Locale CRT structure
Column header Description
Parameter Name Key for which localization is defined.
Locale Policy Locale Policy.

You can use an asterisk (*) as a wildcard, but put the less-restrictive locale policy names at the bottom of the table because the integration scans cross-reference tables from the top.
Value Message shown in Additional Details, or value of the label defined in the Run Summary section.

Example: Comment was not provided.
Description The description that is shown in Additional Details.

Example: The employee is not assigned a shift.
Note:

  • Localization of integration extensions remains optional, but is supported.

  • The cross-reference table (CRT) holds all messages represented with standard English labels; these apply to all locales when the Locale is set to a wildcard (*).

  • Some or all messages can be translated by adding lines to the table in their preferred translation for specific locales. Messages for the most commonly used Locale Policy should be defined at the top of the CRT.

  • Names of the parameters in the CRT column "Parameter Name" must be used as is. If any parameter value needs to be localized for a different Locale Policy, copy the "Parameter Name" with the * Locale Policy, add a new row to the CRT with the appropriate Locale Policy, and then add the localized values in the Message (or Value) and Description CRT columns.

  • Do not enter values in the CRT column "Description" if it is blank.

  • Do not modify placeholders (<>) or the configurable values that are included in the CRT column "Message" (or "Value").

Sample Locale CRT content

Parameter name

Locale policy

Value

Description

Error_CommentNotFound

*

Comment not available.

Message that displays when the Pay Code Comment parameter configuration is incorrect.

Error_DefaultMessage

 

*

Error encountered. Refer to Process Reporting for more details.

Default error message.

Error_EnableEdits

 

*

Provide true or false for Enable Edits.

Message that displays when the Enable Edits parameter configuration is incorrect.

Error_FirstDayIdentifierComment

 

*

Provide valid comment name in Comment for Sickness FirstDayIdentifier parameter.

Message that displays when the Comment for Sickness FirstDayIdentifier parameter configuration is incorrect.

Error_HyperfindNotFound

 

*

Provide Hyperfind or Location or Employee IDs (separated by commas) in the parameter value.

Message that displays when the Hyperfind or Location parameter configuration is incorrect.

Error_IntegrationLookBackDays

 

*

Provide numeric values between 1 and 366 for the Integration Look Back (Days) parameter.

Message that displays when the Integration Look Back Days parameter value is configured with a negative or greater than 366 value.

Error_IntegrationLookForwardDays

 

*

Provide numeric values between 1 and 366 for parameter Integration Look Forward (Days).

Message that displays when the Integration Look Forward Days parameter value is configured with a negative or greater than 366 value.

Error_MessageFormat

 

*

Validation Errors: <parameterList>.

Message that contains mandatory parameters which failed during validation.

Label_DisqualifiedRecords

*

Disqualified Records.

Label that identifies the disqualified transactions count.

Label_FailedMessage

*

Process completed with errors.

Message displayed when failures or errors occur.

Label_FailedRecords

*

Failed Records.

Label that identifies the failed records count.

Label_FailedWithDisqualify

*

Process completed with errors. Click additional details for more information.

Message displayed when records are disqualified.

Label_IntegrationExecutionId

 

*

Integration Execution ID.

Integration execution ID used for process reporting identification .

Label_IntegrationTypeName

 

*

Integration Type.

Label that identifies the import or export integration type name.

Label_IntegrationTypeValue

 

*

Import

Label that identifies the import or export integration type value.

Label_InvalidEmployees

*

Invalid Employees

Label that displays the invalid employees count.

Label_ProcessedEmployees

*

Processed Employees

Label that displays the processed employees count.

Label_SuccessfulRecords

*

Successful Records

Label that displays the count of successful records.

Label_SuccessMessage

*

Integration has completed without errors.

Message that displays when the integration completes without error.

Label_SuccessWithDisqualify

*

Integration has completed without errors, but certain records were disqualified. Click additional details for more information.

Message that displays when the integration completes with partial success.

Message_ChangeNotFound

*

Timecard already updated with sickness pay code.

No changes required.

Message_InconsistentPayCodeData

*

Timecard data for sickness pay code is inconsistent on or after <effectiveDate>

Data is inconsistent on or after <effectiveDate>: Data after this date is not processed.

Message_InconsistentScheduleData

*

The schedule is inconsistent with the Timecard sickness pay code.

Message that displays if the schedule is not present when the sickness paycode is applied.

Message_PeopleInfoNotFound

*

People information details are not available.

Employee not found.

Message_PersonNumber

 

*

Employee Id

???Key value to define the displayed value is Person Number.

Message_PolicyDataInvalid

*

Data configured in the Sickness Policy CRT is invalid.

Sickness Policy data is incorrect.

Message_PolicyDataNotFound

*

Data configured in the Sickness Policy CRT cannot be not found.

Sickness Policies not defined in CRT against Rules CRT.

Message_RuleSetDataInvalid

*

Sickness Rule Set data is invalid.

Sickness Rule Set data in the CRT is invalid

Message_SicknessDataNotFound

*

No sickness period found to process.

No sickness period found to process.

 

After the integrations are deployed and the connection settings and process properties are configured, install the integrations to make them available for running or scheduling.

Note:
  • An integration template is the configured integration that you deploy to an Atom and then install to make available for running or scheduling.
  • An installed integration is a single instance of an integration that is based on an integration template. When you install an integration, you can define parameters or set parameters to be defined when the integration is run.

  1. Select Main Menu  > Administration > Application Setup > Integrations Setup > Install Integrations.

  2. Click Tap Create .

  3. In Integration Name, enter a unique name, such as SicknessPeriodManagement_iPack_v3.

  4. (Optional) Enter a Description.

Note: Do not select API Integration.

  1. In File Access, select None to not select a connection.

  2. (Optional) If the person who runs the integration does not have full access to integrations, select Execute Integration with System Account. This allows the integration access to all APIs in the FAP, and the relevant permissions and data, regardless of the FAP and GDAP of the person who runs the integration.

  3. (Optional) Select Re-Run to allow repeated runs of the integration with the same parameter values as the previous run.

  4. Email Notifications

    (Optional)

    1. Select Yes to send email and control center notifications for integration runs.
    2. Enter the email addresses of the recipients for the following types of run status. For multiple recipients, separate the addresses by a comma, but no spaces:

      In Progress — The integration run started and has not finished.

      Completed — The integration ran successfully without errors.

      Failed — The integration ran successfully, but one or more records have errors. The integration run is treated as failed. If Abort on Failure is configured in an integration set, the integration set stops.

      Completed with Errors — The integration run has errors or could not run.

  5. In Skip Configuration, select None (default) to allow multiple integrations to run at the same time or with the same data without restrictions.

Note: Do not select Allow Minute Interval.

  1. Integration template and parameters

    1. In Integration Template, select SicknessPeriodManagement_iPack_v3.

    2. Click Tap Assign .

    3. In Integration Parameters, you can override default settings. Click Tap Create.

    4. Complete the configuration for each parameter value.

    5. Click Tap Save.

      Repeat this step for each integration control parameter that supports the Sickness Period Management process.

    Integration Parameters
    Parameter name Description / User prompt / Mandatory Template parameter Parameter type
    Hyperfind or Location

    Hyperfind or Location query for whom the integration will run.

    Default = 1 (All Home Locations)

    User prompt = Yes

    Mandatory = Yes

    		 HyperfindOrLocation Hyperfind
    Employee ID

    A comma-separated list of specific employees for whom the integration is run.

    When no value is entered, the integration defaults to the Hyperfind or Locations parameter.

    To process the integration for only a limited group of employees, enter the person numbers as defined in the source system, each separated by a comma (,) but not spaces.

    User prompt = Yes

    		 EmployeeID Text
    Integration Look Back Days

    The number of days before the current date that the integration searches for sickness paycodes.

    Supported values: 0-399.

    Default = 366

    User prompt = No

    Mandatory = Yes

    		 IntegrationLookBackDays Number
    Integration Look Forward Days

    The number of days after the current date that the integration searches for sickness paycodes.

    Supported values: 0-366.

    Default = 180

    User prompt = No

    Mandatory = Yes

    		 IntegrationLookForwardDays Number
    Enable Edits

    Determines the integration behavior during signed-off periods.

    Case-sensitive.

    true: The integration automatically enables edits as part of the adjustment process.

    false (default): When the signed-off period is not enabled for edits, the integration does not add the correction.

    User prompt = No

    Mandatory = Yes

    		 EnableEdits Boolean
    Comment For Sickness FirstDayIdentifier

    Comment that identifies the first day of the previous sickness period in the timecard.

    Used for waiting period occurrence count in the logic.

    Case-sensitive.

    Default = Comment For Sickness FirstDayIdentifier

    User prompt = No

    Mandatory = Yes

    Warning: The value cannot be changed after the first installation of the integration.

    		 CommentForSicknessFirstDayIdentifier Text
    Pay Code Comment

    Comment that will be added to the timecard.

    Leave blank to prevent the addition of a comment.

    Case-sensitive.

    User prompt = No

    Mandatory = No

    		 PayCodeComment Text

  1. Ensure that the generic data access profiles (GDAP) allow access by the people who need to run the installed integrations. Select Administration > Application Setup > Integrations Setup > Access Profiles; see Configure Access to Integrations.

Run integrations to test that the configuration is set up correctly.

Run the integration

  1. Select the integration:
    1. Select Main Menu  > Maintenance > Integrations. 
    2. Click Tap Run an Integration . 
    3. Select the SicknessPeriodManagement_iPack_v3 integration from the list. Click Tap Select. 
    4. (Optional) Enter a unique Integration Run Name to make it easier to identify the run of the integration. Otherwise, the system assigns a default name, which ends with a date and time stamp.
  2. Set parameters as follows:
    • Hyperfind or Location: Select a Hyperfind or location query of employees.
    • Employee ID: To process data for only a limited group of employees, enter the person numbers, as defined in the source system, each separated by a comma, but no spaces.

      For 3 employees: 13997,15556,20012

  3. Select the following:

    • Run Integration: If this is the first time this integration is being run.
    • Re-Run: If this integration has been run before, and the status is not In-Progress, you can run the integration again without entering the parameter values again. Click Tap Yes to continue, or No to not run the integration and to return to the parameter settings.

  4. Wait for the confirmation that the integration completed or failed. Close the panel.
  5. Click Tap Refresh . 
  6. To see details, select the integration run. Select Run Summary.

Check the results

Status indicators

  •  In-Progress: The run of this integration has not yet completed.
  •  Completed: The integration ran successfully without errors.
  •  Scheduled: This integration is scheduled to run later or repeatedly.
  • (Grayed out) Scheduled but Deleted: This integration is scheduled to run, but the integration template has been deleted. When it runs, it will generate an error. To prevent this error, delete the scheduled integration run.
  •  Completed with Errors: The integration ran successfully, but one or more records have errors. The integration run is treated as failed. If Abort on Failure is configured in an integration set, the integration set stops.
  •  Failed: The integration run has errors or could not run.
  • To troubleshoot and resolve errors, do the following:

    Check the Run Summary for details.

    • To troubleshoot all types of errors, or if the Run Summary shows a large number of errors, click tap Go to Additional Details (if available), or click tap the Source File to open and examine the input source file.
    • (Only for import integrations) To troubleshoot and resubmit integrations that have transactional or data errors, click tap Go to Transaction Assistant.

To check the results in more detail:

  1. Click Tap the tile for the integration run.
  2. Click Tap Run Summary to see the results of the integration run.

    Example Run Summary details

    Note: The available details vary by integration and configuration.

    • Integration Run Name: Name of this run of the integration.
    • Process Name: Name of any integration set that includes this integration.
    • Integration Name: Name of the installed integration.
    • Integration Reference ID: Unique identifier for this integration run (to help in troubleshooting errors).
    • User: The person or user account that ran the integration.
    • Integration Type: Import, Export, or None
    • Start Date: Date and time when the integration run started.
    • End Date: Date and time when the integration run finished.
    • Status: In-Progress, Completed, Completed with Errors, or Failed.
    • Records Processed: Number of records that were processed.
    • Records Created: Number of records that were created.
    • Errors: Number of records that failed.
    • Source Files, Output File, and Error Files: For file-based import integrations, use Manage SFTP to access the source and output files on the inbound (source) and outbound (destination) SFTP folders. See the Manage SFTP topic.
  3. Log in to the destination system and ensure that the data has been correctly updated.

Note: You can schedule integrations and integration sets to run once later or at a recurring frequency. See the topic.

API details
API name Type Resource path Description
Process Callback POST /v1/platform/integrations/update_status Update integration status details.
Integration Details POST /v1/platform/integration_executions/ Update the record disqualification details.
Retrieve Locale Policy GET /v1/commons/user_preferences/locale_policy Retrieve locale policy.
Retrieve Comments POST /v1/commons/comments  
Base Persons POST /v1/commons/persons/base_persons/multi_read Validate the employee list in the Employee ID parameter.
Execute Hyperfind POST /v1/commons/hyperfind/execute Validate the Hyperfind or Location ID in the parameter.
Retrieve Persons Extensions POST /v1/commons/persons/extensions/multi_read Retrieve all person details based on person ID.
Timecard Multi Read POST /v1/timekeeping/timecard/multi_read Retrieve all timecard details.
Enable Timecard Edits POST /v1/timekeeping/enable_edits/import Enable edits when editing in signed-off period.
Timecard Paycode Edit POST /v1/timekeeping/timecard Add or delete paycodes in timecard.
Schedule Multi Read POST /v1/scheduling/schedule/multi_read Retrieve employee schedule.
Schedule Audit POST /v1/scheduling/audits/multi_read Retrieve employee shift details.
Retrieve paycode GET /v2/timekeeping/setup/pay_codes Retrieve all paycodes.