Global Time Off Requests (GTOR) Validation Rules

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

This Business Process Extension provides you with more options to validate whether Time-off Requests are in accordance with local regulations; minimum and maximum taking limits that apply to the entire request; and restrictions on combining certain absences in one contiguous period.

Global Time Off Request (GTOR) Validation considers the following rules:

Clubbing Rules: Restrictions on combining certain absences
- Some leave types cannot be combined; that is, they cannot be clubbed together. For example: Sick Leave cannot be taken contiguously with Casual Leave.
- A configurable parameter can disallow any absence request clubbed with a non-working day.
- Clubbing rules are configured to use either basic or advanced rules.
  Basic clubbing rule:
  - Validation is based only on paycode type, such as Sick or Casual Leave.
  - Symbolic duration checks cannot be edited.
  Advanced clubbing rule:
  - Validation is defined for each paycode and combination of symbolic duration.
  For example, the following paycodes should not be clubbed together:
  Casual Leave First Half Day
  Sick Second Half Day
- Clubbing paycodes can be maintained at the location level.
Minimum and maximum Taking Limits validation for the entire request
- Some absence requests have a minimum taking of more than 1 day, while other requests have a maximum taking. For example, Personal Leave cannot be taken for a contiguous period which is shorter than 3 days.
- These limits cannot be enforced for the contiguous period because the Accrual Policy taking limits are only being validated for each day taken.
- This rule, however, can be relaxed with a configurable parameter that allows non-working days as an interruption, thereby allowing the request. By using the configurable parameter, non-working days which occur within the leave request range are considered as an interruption, and the request is allowed.
- Taking limits can be validated using:
  - Employee's location
  - Employee's accrual profile
  - Employee's location and accrual profile
Enhanced Duplicate Request Validation: Restricts duplicate time-off requests for the same day.
- First Half Day Vacation and Second Half Day Personal Leave is allowed.
Mandatory Paycode Comment Validation: Validates the existence of a comment before time-off request submission.
- Some time-off requests are configured to require the addition of a comment.
- This validation workflow prevents submission of a GTOR by checking whether the paycode requires a comment. It then checks the appropriateness of the comment selection. When no comment or an incorrect comment is attached to the paycode in the GTOR, the system displays an error message and prevents the GTOR submission.
Prioritized Overlapping Requests: Allows the new request to potentially override an existing request, depending on the priority setting defined in the decision table.
Hours Overlapping Validation: When an hourly time-off request is submitted, the system performs overlapping validation. If there is an overlap with an existing request, the submission is prevented.
Virtual Accrual Balance Deduction: Upon submitting a global time-off request (GTOR), a placeholder paycode is added. This action temporarily adjusts the accrual balance while the request is in the pending state. Employees are prevented from submitting subsequent GTORs that would exceed the accrual's remaining balance. Upon GTOR approval, the temporary deduction is reversed.

How the rules work

A validation Business Process is available through Request Subtypes, which includes all three rules: Taking Limits, Clubbing, and Duplicate Requests.

Clubbing Rules

Four symbolic amounts are used in the validation: Half Day, First Half Day, Second Half Day, and Full day.

Note: The symbolic amount Half Day is treated the same way as First Half Day.

Clubbing rules scenarios

The following clubbing scenarios represent what is allowed or not allowed.

Interaction with non-working days and public holidays:

Clubbing rules apply when the absences are separated by either a non-working day or a public holiday.
These days do not interrupt the contiguous period and clubbing is applied.

For example, the following scenarios are both disallowed:

However, to allow flexibility in defining what counts as non-working days, you can relax the rule by using the Include Non Working Day column in the GTOR_Validation_v5_SimpleClubbingValidate_Configurations decision table.

Note: This scenario requires that you add an absence paycode of "Off” in the schedule to identify weekends or days off.

In the following example, Casual Leave and Sick are allowed to be taken because the period is no longer contiguous; that is, an empty day is in between them.

Clubbing rules validation can be qualified for the employee's location.

Minimum and maximum contiguous days taking limits

This process contains a decision table that controls the number of taking limits for each absence paycode.

You are not required to specify both minimum and maximum limits. They can be left empty when no limit applies.
Absence paycodes that are not found in the decision table are not limited by the process (Accrual Policy taking limits might still apply).

For example: The system validates the following schedule as a contiguous period:

But with an empty day between Casual Leave paycodes, the sequence is interrupted and it is not a contiguous period:

Taking limits can be qualified using employee's location, accrual profile or both.

Prioritized Overlapping Requests

Depending on the priority setting of an absence code, a new request overrides an existing request.

When an absence request is submitted, if the new request contains a higher priority absence code, it automatically overrides the existing absence. Conversely, when the absence request contains a lower priority absence code, it cannot be submitted.

Virtual Accrual Balance Deduction

Upon initiation of a time-off request, the accrual balance is temporarily adjusted by the requested amount. This prevents employees from submitting a time-off request that potentially exceeds the available balance.

When the request is processed, the temporary deduction is automatically removed, and the actual adjustment occurs.

Duplicate Requests

This process eliminates limitations in the current duplicate request validation process. Days (full, half, first half, and second half) and hours durations are supported.

Note: Half Day and First Half Day are treated the same in the validation process.

Example: Same day requests for First Half Day Vacation and Second Half Day Personal Leave are allowed.

Mandatory Paycode Comment

This process prevents submission of an absence request when a required comment is not provided.

When submitting an absence request paycode that must be accompanied by a comment, the validation process intercepts the request and warns the employee if the request has an invalid or missing paycode comment.

Until the employee adds the comment by using the review + add comment action, the submit button remains inactive. After editing the request by adding one of the designated comments for the paycode, the request is routed to the manager for approval.

Considerations and limitations

This Business Process is supported only from desktop, mobile, or tablet devices. It is not supported on data-collection devices, such as timeclocks.

Always keep an empty "Default" line as the last entry in the decision tables. Without this last line, the decision tables do not work.
As a best practice, insert new lines of data in decision tables above the empty "Default" line.
Blank schedules are treated as working.
Non-working days are treated as Full Day.
The validation template considers non-working paycodes located in:
- Schedule Planner
- Timecard
- Holiday credit rules
The primary job assignment in people information is treated as the location.
The validation template considers visible and hidden paycodes utilized during the taking, clubbing and non-working day.
Manager actions on employee time-off requests override all validations with the exception of Prioritized Overlapping Requests and Mandatory Paycode comments.
Multiple assignments are only supported for Prioritized Overlapping Requests and Placeholder Paycode functionality.
Do NOT edit the prioritization comment notes that are added to the paycode.
Do NOT edit the placeholder comment notes that are added to the paycode.
Prioritized Overlapping Requests and Overlapping Validation models cannot be enabled simultaneously.
When Prioritized Overlapping Requests functionality is enabled, low priority request are NOT allowed if a high priority request already exists.
When a time-off request is canceled, all requests for that day must also be canceled in order for the shift to be restored. The business process does NOT automatically restore the shifts.
Employees are allowed to submit requests for a day by specifying the duration using hours or a symbolic amount, such as Full Day, First Half Day, or Second Half Day. Requests that mix different types of durations, such as Hours that overlap with Full Day, First Half Day, or Second Half Day are NOT allowed due to prioritization and overlapping validation. These cases result in validation errors.
When the placeholder paycode is assigned and the employee time-off request is approved after the employee timecard is signed-off, the workflow enables editing, and then inserts a paycode with a negative amount in the timecard to eliminate the placeholder paycode.

Before you start

Before you configure this business process model, you must configure the following prerequisites:

Non-working paycodes

Create the paycodes that your business considers non-working days, such as Day Off and Public Holiday. This is not a combined paycode.

Placeholder paycodes

Create paycodes to use as placeholders that correspond with each time-off-related paycode. The same prefix must be used when defining the name of each placeholder paycode. For example, use the prefix Temp to create TempSick and TempVacation placeholder paycodes that correspond with the Sick and Vacation paycodes.

Note:

The placeholder prefix activates Placeholder Paycode functionality. Your business must use the same prefix in the naming convention when defining the placeholder paycodes.
As a best practice, configure placeholder paycodes as hidden.

After creating the placeholder paycodes, edit the appropriate Accrual Policies by moving the placeholder paycodes from the Select Pay Codes list.

Comments

Create two active comments that are defined using the Pay Codes category selection. One comment is attached by the prioritization adjustment to the employee schedule paycode. The second comment is attached to the placeholder paycode in the employee Timecard.

Holiday credit rules

Create holiday credit rules to capture credited hours for public holiday paycodes. Assign to all employees.

Configure the GTOR Validation Rules

Version history

Version	Description
1	Initial release.
1.1	Process is now compatible with JSON response changes for the Request API. Includes error handling at script level and removes sequencing from condition gateways.
1.2	The leave validation process is now independent of the request subtype allowing an employee to apply for leave from multiple request subtypes.
2	Taking and clubbing scenarios now include or exclude non-working days, The business rule is configurable using the location and accrual profile for takings scenarios. The business rule is configurable using the location for clubbing scenarios. The business process is now optimized for improved performance and maintainability.
2.1	With takings scenarios, when the leave includes non-working days, total leave days equals the Minimum Taking value configured in the TakingLimits_Configuration table. When Include Non-Working Days in the TakingLimits_Configuration table is set to No, the validation template rejects the request.
3	Non-working days can be specified using the holiday credit rule, direct timecard entry, and scheduled paycodes. The business logic remains the same as previous versions.
4	Mandatory paycode comment validation is now supported.
4.1	Support is extended for taking limits that exceed 90 days.
4.2	Employees are now allowed to submit more than one hours-based time-off requests for the same day.
4.3	Addressed an issue related to non-working paycodes in taking limits.
4.4	Enhanced the minimum and maximum values validation logic to encompass non-working days located at the beginning or end of the request period that occur within the time-off request date range.
4.5	Enhanced to support the upgraded Groovy version of Activiti v2.x.
5	Enhanced to support new optional functionality: Prioritized overlapping requests: Allows the new request to potentially override an existing request, depending on the priority setting defined in the decision table. Hours overlapping validation: When an hourly time-off request is submitted, the system performs overlapping validation. If there is an overlap with an existing request, the submission is prevented. Virtual Accrual Balance Deduction: Upon submitting a global time-off request (GTOR), a placeholder paycode is added. This action temporarily deducts the accrual balance while the request is in the pending state. Employees are prevented from submitting subsequent GTORs that would exceed the accrual's remaining balance. Upon GTOR approval, the temporary deduction is reversed.

Migrate the process model to the customer tenant

Migrate the GTOR_Validation_v5 process model to the customer tenant using Setup Data Manager (SDM).

Log in to the appropriate tenant.
Go to Main Menu > Administration > Setup Data Manager.
Select the Source tenant where the Process Model resides, and select the template to copy. It is a .zip file. A message appears in the Source column: Source: Import from <filename>.zip.
Click Tap Review and Publish. The Publish Summary panel appears.
Review the Publish Summary panel. It lists the items that were extracted from the migration file. If you approve, click tap Publish with Comment or just Publish.
Click Tap Go to Publish History at the bottom of the panel to view the status of the data transfer. The Publish History page contains a table that lists the items you have published. If there were errors during the transfer, the button under the Errors column for that row is black.
To view details, click tap the appropriate row and click tap View Selected.
On the History for publish run page, click tap Show all to view the setup data that you published, and the errors that occurred, if any, listed by item type and name.

Deploy the process models

Note:

Process models must be redeployed every time any changes are made to an existing model.

GTOR validation includes multiple mandatory process models. You must deploy each process model to ensure essential GTOR operability.

GTOR - Validation workflows
Process name	Description
GTOR_Validation_v5_PreProcess1	Performs validation for: Overlapping Clubbing Taking Mandatory Paycode Prioritization This process must be attached in Pre-Processing Validation Action.
GTOR_Validation_v5_PostProcess1	Adds placeholder paycode in employee timecard after the request is submitted.
GTOR_Validation_v5_PostProcess2	Performs prioritize paycode adjustments.
GTOR_Validation_v5_PreAndPost_Process2	Performs validation for: Mandatory Paycode Prioritization The process also handles placeholder paycode deletions.

Follow these steps to deploy the process model. For detailed information, see the online help topic Deploy Business Process Models.

From the Main Menu, go to Application Setup > Business Process Setup > Process Models.
Select the process and click tap Deploy .
On the Business Process page, configure the required parameters and deployment dates.

Note: Select Hide for the Action List, Tile List and GoTo List options.

Select Validation from the Template Categories.
Click Tap Save and Return.

Application configuration setup

After deploying the business process models, you must configure the following:

Request Subtype Transition

Define request transitions to suspend a request between state transitions, such as pending and approved, while a business process completes a task.

Enter a name, such as GTOR Validation, and then attach the business processes to the appropriate From State and To State combinations for the employee requests and manager approvals. Refer to the Validation Actions table.

Validation Actions
From State	To State	Pre-Processing	Post-Processing
Draft	Submitted	GTOR_Validation_v5_PreProcess1	GTOR_Validation_v5_PostProcess1
Draft	Approved	GTOR_Validation_v5_PreProcess1	GTOR_Validation_v5_PostProcess2
Submitted	Pending	GTOR_Validation_v5_PreAndPost_Process2	---
Submitted	Approved	GTOR_Validation_v5_PreAndPost_Process2	GTOR_Validation_v5_PostProcess2
Pending	Approved	GTOR_Validation_v5_PreAndPost_Process2	GTOR_Validation_v5_PostProcess2
Submitted	Refused	---	GTOR_Validation_v5_PreAndPost_Process2
Submitted	Canceled	---	GTOR_Validation_v5_PreAndPost_Process2
Pending	Refused	---	GTOR_Validation_v5_PreAndPost_Process2
Pending	Canceled	---	GTOR_Validation_v5_PreAndPost_Process2
Approved	Canceled	---	GTOR_Validation_v5_PostProcess2
Cancel Submitted	Canceled or Canceled Approved	---	GTOR_Validation_v5_PostProcess2

See the Request Subtype Transitions topic.

Note: Because edits can affect pending requests, create new request subtype transitions rather than editing current transitions.

Attach the Request Subtype Transition to the Request Subtype

Select the Request Subtype that you want to use. In Request Cancellation, select Allow with Schedule Restoration. Scroll to the Request Subtype Transition and select your newly created Request subtype transition, for example, GTOR Validation.

Caution:

Do NOT select the Half option from Default Symbolic Amount when defining the request subtype.

See the Configure Request Subtypes topic.

Customize error translation

Translate or customize the errors in the user interface using a language or terminology that is familiar to your users.

Identify the content to modify
1. Language — Select the language
2. Country — Select the country
3. Domain — Select one or more domains (such as Scheduling or Timekeeping) to export. Depending on the domain or domains selected, the corresponding properties are listed in the Group field.
4. Group — Select the applicable property files from the list. If you leave the top field blank, all property fields are selected.
Export the property files.
Edit the Excel file.
Import the Excel file.
Verify the changes and save the Excel file.

Error codes used in this template
Sr. No.	Error Code	Error Message	Scenario
1	WFP-01155.MESSAGE	Your time-off request has failed because of validation error. Please check your control center and submit your time-off again.	All Validations
2	WFP-01135.MESSAGE	Request processing failed. Please contact System Administrator.	Custom Message

Workflow notification

Create a generic notification, such as GTOR Error Notification, that is sent when an error is captured during process execution.

During configuration, enter the <ErrorValidationMessage> placeholder in the Long Message.

Placeholder details
Placeholder	Description
<`ErrorValidationMessage`>	Displays any error message captured during process execution.

See the Generic notifications topic.

Configure decision tables in the process model

Note: The process for configuring and deploying Business Process Extensions is the same as all Business Process models.

Decision tables are configurable based on user requirements. These tables are dynamic decision tables that can be modified without redeployment of the process model.

How to edit or view the decision tables

From the Main Menu, go to Administration > Application Setup > Business Processes Setup > Process Models.
Click Tap Filter Columns, and then search for GTOR_Validation_v5 under Model Name.
Select the GTOR_Validation_v5 process and click tap Edit . The process model enters edit mode.
Select the Decision Tables tab.
Click Tap Everyone's, and then search for GTOR_Validation_v5. Select the decision table to edit.
Click Tap Decision Table Editor to add or update the rows in the table.
Click Tap Save and close.

Edit the following decision tables:

Caution: Values entered in the decision tables are case-sensitive, and must match configured values in UKG Pro Workforce Management™

GTOR_Validation_v5_Parameters — Controls the active validation processes in the workflow.

GTOR Validation Parameters decision table structure
Parameter name	Description	Default value
ValidationClubbing	Enables clubbing rule validation. `Yes` — enables the validation. `No` — does not enable the validation. Note: If ValidationClubbing=`Yes` and SimpleClubbing=`Yes`, then the Simple Clubbing validation rule is validated by the template. If ValidationClubbing=`Yes` and SimpleClubbing=`No`, then the Advanced Clubbing validation rule is validated by the template.	`Yes`
ValidationTakings	Enables takings validation. `Yes` — enables the validation. `No` — does not enable the validation.	`Yes`
ValidationOverlapping	Enables overlapping validation. `Yes` — enables the validation. `No` — does not enable the validation.	`Yes`
SimpleClubbing	Enables simple clubbing. `Yes` — enables the functionality. `No` — does not enable the functionality. Note: If ValidationClubbing=`Yes` and SimpleClubbing=`Yes`, then the Simple Clubbing validation rule is validated by the template. If ValidationClubbing=`Yes` and SimpleClubbing=`No`, then the Advanced Clubbing validation rule is validated by the template.	`Yes`
MandatoryPayCodeComment	Enables mandatory paycode comment. `Yes` — enables the functionality. `No` — does not enable the functionality.	`Yes`
Prioritization	Enables prioritization paycode adjustment. `Yes` — enables the functionality. `No` — does not enable the functionality. Caution: Setting both ValidationOverlapping and Prioritization = `Yes` is not allowed. When ValidationOverlapping = `Yes`, you must configure Prioritization = `No.` When ValidationOverlapping = `No` and Prioritization = `Yes`, you must configure PrioritizationPaycodeComment with a comment that exists in the application.	`No`
PlaceHolderPaycodePrefix	Activates the placeholder paycode functionality. Enter the prefix used to identify the placeholder paycodes. When left blank, the functionality is NOT enabled. Caution: When PlaceHolderPaycodePrefix is not null, you must configure PlaceHolderPaycodeComment with a comment that exists in the application.
ErrorNotification	Workflow notification name that is sent in the event of a processing failure.	`GTOR Error Notification`
PlaceHolderPaycodeComment	Comment name that the process attaches to the placeholder paycode. Caution: When PlaceHolderPaycodePrefix is not null, you must configure PlaceHolderPaycodeComment with a comment that exists in the application.
PrioritizationPaycodeComment	Comment name that the process attaches to prioritized paycode.

GTOR_Validation_v5_InternalParameters — Controls internal GTOR validation parameters.

GTOR Validation Internal Parameters decision table structure
Parameter name	Description	Default value
DurationFullDay	Full day symbolic value.
DurationHalfDay	Half day symbolic value.
DurationFirstHalfDay	First half day symbolic value.
DurationSecondHalfDay	Second half day symbolic value.
Admin	Internal user; do not change.	`SERVICES-LEVEL3`
ActivityVariableRequestItem	Internal value; do not change.	`RequestItem`
DurationHours	Hours symbolic value.	`HOURS`
SubmittedStatus	Submitted status symbolic value.	`SUBMITTED`
ApprovedStatus	Approved status symbolic value.	`APPROVED`
PendingStatus	Pending status symbolic value.	`PENDING`
CancelledStatus	Canceled status symbolic value.	`CANCELLED`
CancelledApprovedStatus	Canceled approved status symbolic value.	`CANCELLEDAPPROVED`
RefusedStatus	Refused status symbolic value.	`REFUSED`
CancelledRefusedStatus	Canceled refused status symbolic value.	`CANCELLEDREFUSED`
CancelSubmitted	Cancel submitted symbolic value.	`CANCELLEDSUBMITTED`
DraftStatus	Draft status symbolic value.	`DRAFT`
ActivitiVariableRequestID	Request ID	`RequestID`
ActivitiVariableStartDate	Start date	`StartDate`
ActivitiVariableEndDate	End date	`EndDate`

GTOR_Validation_v5_TakingLimits_Configurations — Contains the minimum and maximum number of takings allowed for each paycode type.

GTOR Validation Taking Limits Configurations decision table structure
Validation type	Description
Primary Job	Input parameter for primary job.
Accrual Profile Name	Input parameter for accrual profile.
Taking Pay Code Name	Input parameter for paycode. Caution: Paycode names must match the tenant default locale.
Minimum Taking	Input parameter for minimum value.
Maximum Taking	Input parameter for maximum value.
Taking Output Status	Output parameter.
Include Non-Working Day	Output parameter to include non-working days. `Yes` — include non-working days. `No` — do not include non-working days. When the parameter = `Yes`, Taking Pay Code Name can include a non-working day.

Note:

The taking validation template uses the accrual profile from People Information or the employment term. If an employment term is assigned to an employee and that employment term has an accrual profile, the validation uses the accrual profile found in the employment term.
If an accrual profile is not found in people information or an assigned employment term, then validation is not performed.
The taking validation template uses the accrual profile with the primary job location of the employee to validate rules. For single day leave requests, the accrual profile applicable on the leave day is used. For two or more days of leave requests, the accrual profile applicable on the first day of leave is used.

For example: An employee has a Part-time accrual profile from the beginning of time until 30 Nov 2021 and a Full-time accrual profile from 1 Dec 2021 through forever.

If the employee requests leave for 25 November 2021, the template uses the Part-time accrual profile for validation.
If the employee requests leave for 25 November 2021 — 2 December 2021, the template uses the Part-time accrual profile for validation.
If the employee requests leave for 1 December — 2 December 2021, the template uses the Full-time accrual profile for validation.

GTOR_Validation_v5_NonWorkingPaycodes_Configurations — Contains the non-working paycodes required for taking and clubbing validations.

GTOR Validation Non-Working Paycodes Configurations decision table structure
Validation name	Description
Serial number	Sequential numeric value which starts from 1. Serial number must always be in sequential incremental order without gaps.
Non Working Pay Code Name	Non-working and public holiday paycode names which are configured in UKG Pro Workforce Management™. Caution: Paycode names must match the tenant default locale.

GTOR_Validation_v5_ClubbingValidate_Configurations — Contains the paycodes for which clubbing rules are validated.

GTOR Validation Clubbing Validate Configurations decision table structure
Column name	Description
Primary Job	Primary job input parameters. Note: A wildcard in the location position represents all jobs in the same location.
Clubbing Pay Code Name	Paycode input parameters. Caution: Paycode names must match the tenant default locale.
Validate Pay Code Output	Output parameter. Values include: `Valid` / `Not Valid`
Include Non Working Day	Determines whether to include non-working days. `Yes` — include non-working days. `No` — do not include non-working days. When the parameter = `Yes`, Clubbing Pay Code Name can include a non-working day.

GTOR_Validation_v5_ComplexClubbingValidate_Configurations — Contains the paycodes that cannot be clubbed together when choosing Advanced Clubbing validation.

GTOR Validation Complex Clubbing Validate Configurations decision table structure
Column name	Description
Primary Job	Primary job input parameters. Note: A wildcard in the location position represents all jobs in the same location.
Comparison Pay Code	Comparison paycode input parameters. Caution: Paycode names must match the tenant default locale.
Comparison Duration	Comparison paycode duration input parameters. Values include: `FULL_DAY` / `HALF_DAY` / `FIRST_HALF_DAY` / `SECOND_HALF_DAY`
User Applied Pay Code	Applied paycode input parameters. Caution: Paycode names must match the tenant default locale.
User Applied Duration	Applied paycode duration input parameters. Values include: `FULL_DAY` / `HALF_DAY` / `FIRST_HALF_DAY` / `SECOND_HALF_DAY`
Clubbing Output	Output parameter. Values include: `Valid` / `Not Valid`

GTOR_Validation_v5_SimpleClubbingValidate_Configurations — Contains the paycodes that can be clubbed together.

GTOR Validation Simple Clubbing Validate Configurations decision table structure
Column name	Description
Primary Job	Primary job input parameters. Note: A wildcard in the location position represents all jobs in the same location.
Simple Comparison Pay Code	Comparison paycode input parameters.
Simple User Applied Pay Code	Applied paycode input parameters.
Clubbing Output Status	Output parameter. Values include: `Valid` / `Not Valid`

Note:

As a best practice, add all "Not Valid" paycode combinations to the Simple Clubbing Validate decision table.

GTOR_Validation_v5_PayCodePriority — Defines the paycode priority for all time-off-related paycodes used by the prioritization functionality.

GTOR Validation Paycode Priority decision table structure
Column name	Description
PaycodeName	Paycode name. Caution: Paycode names must match the tenant default locale.
PaycodePriority	Paycode priority. Caution: PaycodePriority must be configured with unique numeric values, with the number "1" representing the highest priority. Zero (0) is NOT a valid value. Do NOT repeat a PaycodePriority value on more than one row in the decision table.

GTOR_Validation_v5_Locale — Allows customization of the text in the workflow form and notifications for different locales.

GTOR Validation — Locale decision table structure
Column header	Description
Key	Key for which localization is defined.
Locale	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.
Message	Message shown in Additional Details, or value of the label defined in the Run Summary section. Example: Comment was not provided.

Sample Locale decision table content
Key	Message	Description
Error_OverlappingValidation	Your request conflicts with a previously approved request. Please check the request information and resubmit.	Message that indicates when an overlapping validation error occurs.
Error_PrioritizationValidation	Time-off request with a paycode of higher priority exists. Please check the request information and resubmit.	Message that indicates when a prioritization error occurs.
Error_ClubbingValidation	Your request conflicts with an absence clubbing rule. Please check the request information and resubmit.	Message that indicates when a clubbing error occurs.
Error_TakingValidation	Your request conflicts with a minimum/maximum taking rule. Please check the request information and resubmit.	Message that indicates when a taking validation error occurs.
Error_MandatoryPaycodeCommentValidation	Invalid Pay Code Comment provided, or Mandatory Pay Code Comment is missing. Please check the comment and resubmit the time-off.	Message that indicates when a mandatory paycode comment validation error occurs.
Error_CrossOverlappingValidation	Your request conflicts with a previously approved request of hourly/day amount type. Please check the request information and resubmit.	Message that indicates when overlapping request types differ. For example, an hour-type request is submitted on top of a day-type request.
Error_CrossPrioritizationValidation	Your request conflicts with a previously approved request of hourly/day amount type. Please check the request information and resubmit.	Message that indicates when overlapping request types differ during prioritization validation. For example, an hour-type request is submitted on top of a day-type request.
Error_BothOverlappingPrioritizationValidation	Both Overlapping and Prioritization Validation is marked as Yes, please select one among these.	Message that indicates when both Overlapping and Prioritization are set to Yes.
Error_PlaceHolderPaycodeNotFound	Placeholder paycode not found in application.	Message that indicates when a placeholder paycode cannot be found in the application.
Error_GenericErrorMessage	Error encountered, please contact system administrator.	Generic error message.
Message_NoteRequestId	RequestID	Prioritize paycode comment note 1 contents.
Message_NoteAmount	Amount	Prioritize paycode comment note 2 contents.
Message_PrioritizationNote	Paycode Prioritize	Prioritize paycode comment note 3 contents.
Error_PaycodeNotFound	Paycode not found in Priority Decision Table.	Message that indicates when a paycode cannot be found in the prioritization decision table.
Error_PrioritizationCommentNotFound	Prioritization Comment Not Found in Application	Message that indicates when a prioritization paycode comment cannot be found in the application.

Note:

Localization of business process workflows remains optional, but is supported.
The decision table 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 decision table. Text within tags ("<>") must not be changed.
Names of the parameters in the decision table 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 decision table with the appropriate Locale Policy, and then add the localized values in the Message column.
The last row in the decision table must remain empty ("!=empty".)

Shared_MandatoryPayCodeComment — Contains a list of paycodes that require a comment and identifies the associated acceptable comments.

Shared Mandatory Paycode Comment decision table structure
Column name	Description
Pay Code	Identifies paycodes that require a mandatory comment. Each paycode must be configured in UKG Pro Workforce Management™. Caution: Paycode names must match the tenant default locale.
Comments	A semicolon-separated list of comments that identifies the acceptable comments for the associated paycode. Each comment must be configured in UKG Pro Workforce Management™. Caution: Do not create comments with names such as Null or Default.

Note: The Shared_MandatoryPayCodeComment decision table is utilized by other business processes. It is recommended that a backup of the existing table is created before deploying other business processes that use the same decision table.

APIs

API details
API Name	Type	Resource Path	Description
Retrieve User Preferences for Current User	GET	/v1/commons/user_preferences/locale_policy?userCurrent=true	Returns user preferences for the current user or tenant.
Retrieve Paycodes	POST	/v1/timekeeping/setup/pay_codes/multi_read	Returns one or more paycodes available to the logged-in manager by object references.
Retrieve Time Off Requests as Manager	POST	/v1/scheduling/timeoff/multi_read	Returns one or more time-off requests matching specified search criteria, corresponding to a set of time off request IDs or employees.
Retrieve Persons	POST	/v1/commons/persons/extensions/multi_read	Returns multiple person records based on search criteria. Search criteria include personid, personnumber, jobassignmentid, username, useraccountid, and badgenumber.
Retrieve Schedule	POST	/v1/scheduling/schedule/multi_read	Returns a schedule pertaining to a set of employees or locations within a specified date range. The data included in the response can be specified via the select parameter.
Retrieve Employment Term by ID	GET	/v2/timekeeping/setup/employment_terms/${employmentTermID}	Returns an employment term by ID.
Retrieve Timecard Data for Multiple Employees	POST	/v1/timekeeping/timecard_metrics/multi_read	Returns timecard data for a set of employees or locations.
Retrieve Comments as Manager	GET	/v1/commons/comments?id=${commentId}	Returns a filtered list of Comments.
Retrieve Timecards as Manager	POST	/v1/timekeeping/timecard/multi_read	Returns a list of timecards based on the employees or Hyperfind details provided. Required parameters include employee ID or person number along with a date range or symbolic period ID.
Update Timecard as Manager	POST	/v1/timekeeping/timecard	Updates a timecard for an employee as a manager. You can add, update, or delete punches, paycode edits, hours worked, and/or exception comments.
Retrieve Signoffs as Manager	GET	/v1/timekeeping/timecard_signoffs?person_num=${personNumber}	Returns a Boolean indicator of whether or not automatic signoff is enabled.
Enable Edits Bulk Update		/v1/timekeeping/enable_edits/import	Returns a list of employees with enabled edits. Supports partial success.
Retrieve Schedule Audits	POST	/v1/scheduling/audits/multi_read	Returns a set of audits according to the specified criteria.