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.
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.
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.
- 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
, orSecond 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 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.
- 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.
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:
|
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
- 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.
Process name | Description |
---|---|
GTOR_Validation_v5_PreProcess1 |
Performs validation for:
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:
The process also handles placeholder paycode deletions. |
Follow these steps to deploy the process model. For detailed information, see the online help topic
- 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.
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
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
.
Do NOT select the Half
option from Default Symbolic Amount when defining the request subtype.
See the
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
- Language — Select the language
- Country — Select the country
- 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.
- 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.
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 | Description |
---|---|
<ErrorValidationMessage > |
Displays any error message captured during process execution. |
See the
Configure decision tables in the process model
Note: The process for configuring and deploying Business Process Extensions is the same as all
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:
GTOR_Validation_v5_Parameters — Controls the active validation processes in the workflow.
Parameter name | Description | Default value |
---|---|---|
ValidationClubbing |
Enables clubbing rule validation.
Note:
|
Yes
|
ValidationTakings |
Enables takings validation.
|
Yes
|
ValidationOverlapping |
Enables overlapping validation.
|
Yes
|
SimpleClubbing |
Enables simple clubbing.
Note:
|
Yes
|
MandatoryPayCodeComment |
Enables mandatory paycode comment.
|
Yes
|
Prioritization |
Enables prioritization paycode adjustment.
Caution:
|
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.
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.
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.
When the parameter = |
- 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.
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.
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: |
Include Non Working Day |
Determines whether to include non-working days.
When the parameter = |
GTOR_Validation_v5_ComplexClubbingValidate_Configurations — Contains the paycodes that cannot be clubbed together when choosing Advanced Clubbing validation.
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: |
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: |
Clubbing Output |
Output parameter. Values include: |
GTOR_Validation_v5_SimpleClubbingValidate_Configurations — Contains the paycodes that can be clubbed together.
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: |
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.
Column name | Description |
---|---|
PaycodeName |
Paycode name. Caution:
Paycode names must match the tenant default locale. |
PaycodePriority |
Paycode priority. Caution:
|
GTOR_Validation_v5_Locale — Allows customization of the text in the workflow form and notifications for different locales.
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. |
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. |
-
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.
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.
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. |