Skip to main content

​
Purpose

The 2cloudnine 3B WFM Integration provides a flexible and seamless solution for integrating the 3B WFM and 2cloudnine applications. Its primary purpose is the creation and updating of 2cloudnine Assignments, Timesheet and Timesheet Entries via the processing of 3B WFM Shifts. With the 2cloudnine 3B WFM Integration, a scheduler is able to manage their workforce using 3B WFM’s native functionality and have the data seamlessly flow to 2cloudnine. Back office functions are then able to pick up and manage this data without a need to interact with the 3B WFM records. The purpose of this user guide is to provide instructions related to the setup, functionality and processing of Shift records and the data flow to 2cloudnine. The intended audience for this document is system Administrators, Schedulers, Payroll and finance users.

​
Configuration Steps

Installation and Core Setup Please refer to the 2clounine 3B WFM Integration Configuration and Implementation Guide. Required Fields Please refer to the 2clounine 3B WFM Integration Configuration and Implementation Guide for all required fields that must be added to the page layouts used through the integration. Failure to add and make fields required will result in integration failures.

​
Processing Shifts

The 3B WFM Shift record is used to trigger the 2cloudnine 3B WFM Integration which occurs when the field Integration Pending is checked (unchecked by default). All Shift records where this checkbox is selected will be automatically scheduled to be integrated when the next batch job is scheduled to run. The timing of the scheduled batch job is defined by your system administrator as part of the installation and setup of the 2cloudnine 3B WFM Integration (Default script is every 5 minutes). The flagging of a Shift record to be processed is defined by the customer and updated using a Salesforce flow. The reason to flag shifts at customers discretion ensures each customer can determine their own criteria regarding the processing of shifts. As a baseline we recommend shifts are only flagged for Integration when they are considered complete from a data perspective and then subsequently anytime specific data points are changed. For example changing the Shift’s time, contact, job role or adding/removing Project Codes would typically flag a shift to be processed.

​
Sent to Payroll

In order for a processed Shift to create 2cloudnine records, the checkbox field on the Shift ‘Sent to Payroll’ must be checked. Like the flagging of a Shift to be processed, the checking of ‘Sent to Payroll’ is also defined by the customer and updated using a Salesforce flow. If a Shift is processed with Sent to Payroll unchecked, no records are created. In the event a Shift has been processed with Sent to Payroll checked and then processed again with Sent to Payroll unchecked, the related Timesheet Entry record will be deleted. This ensures Shifts, such as those cancelled, can still remain Published for the end user to see via the mobile app, but removed from 2cloudnine for payment. The related Timesheet and Assignment records when a Shift is no longer Sent to Payroll will remain, as it is likely they will be used from a subsequent Shift.

​
2cloudnine Records

As noted above, the processing of 3B WFM Shift records is the trigger point for the 2cloudnine 3B WFM Integration to create/update the related 2cloudnine records. The following objects and subsequent records are created via the integration. Assignment The first 2cloudnine record created is the Assignment and contains data from the Agreement, 3B Job and Shift records. Assignments are created and subsequently updated based upon the matching field ‘AssignmentString’ located on both the Shift and Assignment records. By default, the ‘AssignmentString’ is defined as a ‘3B Job + Contact’ meaning for each unique 3B Job an Employee is in, a new Assignment record will be created. Where a shift is processed with the same Job Role and Contact, the integration will simply use the existing Assignment record. This ensures a unique Assignment is not being created for every Shift.
ExampleJohn Smith is in a 3B Job called ‘Nurse Level 1’. When the first shift for John is processed under this Job, a 2cloudnine Assignment is created. John is then placed into another Shift under this same Job and the shift again processed. The integration will lookup and find the existing assignment and no new Assignment is created.John Smith is then placed into a new Shift but under the Job ‘Nurse Level 2’ and the shift is processed. In this instance, a new Assignment will be created because John is now in a new Job.If another shift is processed for John’s ‘Nurse Level 1’ Job, the first Assignment will again be used.Any customer that wishes to change the AssignmentString can do so by updating the AssignmentString on the Shift record using a Salesforce record triggered flow (fast update not available). The custom AssignmentString will then be used by the integration when determining when to create unique Assignment records.Refer Assignment for all 3B WFM to 2cloudnine Assignment mappings.
Timesheet The second 2cloudnine record created in the integration is the Timesheet. The Timesheet record is used to define the frequency of the Timesheet which will be processed from 2cloudnine Payroll, typically in-line with the desired pay schedule As noted in the required fields section, the Timesheet calendar is defined on the 3B Job meaning a unique Timesheet is created based upon the 3B Job > Timesheet Calendar frequency for the date in which the Shift record is processed. The 2cloudnine 3B WFM Integration supports Weekly, Fortnightly and Monthly Timesheet Calendars. Please refer to the Configuration and Implementation guide for details related to setting up Timesheet calendars.
ExampleJohn Smith’s Job has a related Timesheet Calendar with a Weekly frequency. A Shift record was processed with a date of 16/08/2022 which triggered a Timesheet to be created for the weekly period 15/08/2022 - 21/08/2022.John works another Shift under the same Job on the 18/08/2022 and the shift is processed. This time the integration finds the existing Timesheet within that period and no new Timesheet is created.The following week John works another shift under this Job dated 22/08/2022. When this Shift is processed, the integration does not find an existing Timesheet for that period so a new Timesheet record is created with a period of 22/08/2022 - 28/08/2022.Refer Timesheet Mapping for all 3B WFM to 2cloudnine Timesheet mappings.
Timesheet Entry The final record created in the 2cloudnine 3B WFM Integration is the Timesheet Entry. A Timesheet Entry record is directly related to the date in which Shift which was processed meaning a single Shift is always related to a single Timesheet Entry. The Timesheet Entry record contains specific data related to the Shift record such as the date, start time/end time, breaks and Project Codes (see mapping table below for all mapped fields). Where a Shift record is updated and processed again, the related Timesheet Entry will be updated with the related changes to the Shift record.
ExampleUsing the above example in which 3 Shift records were processed for 16/08/22, 18/08/22 and 22/08/22 would result in 3 Timesheet Entry records being created and directly related to the individual Shift records.Refer Timesheet Entry Mapping for all 3B WFM to 2cloudnine Timesheet Entry mappings.
Payee The Payee is an optional record that can be created automatically by the 2cloudnine 3B WFM Integration. Where the related 3B Agreementt has Auto Create Payee checked, the integration will automatically create a Payee record where one is not found based upon the settings on the Agreement (see Payee and Payment Entity Selection Below). Payees that are automatically created are also related to the Assignment and Timesheet of the processed Shift. Refer Payee Mapping for all 3B WFM to 2cloudnine Payee mappings.

​
Shift Times

The 3B WFM Shift record contains a number of optional fields that are used by 2cloudnine Payroll during the interpretation of Timesheet records. Date & Time Capture To provide maximum flexibility in capturing date and time values, the 2cloudnine 3B WFM integration leverages custom fields on the Shift object to record and transmit shift timing data. The following custom fields are used:
  • 3B Start Date (Date field)
  • 3B Start Time (Time field)
  • 3B End Date (Date field)
  • 3B End Time (Time field)
Important: These fields are not populated by the 2cloudnine integration. Instead, they are managed by 3B, using their own logic based on existing Scheduled and Actual date/time fields in the 3B product. This approach allows for flexibility around shift time zones and supports client preferences for using either scheduled or actual times. As such, any integration involving these fields must be coordinated directly with 3B. Additionally, the 2cloudnine integration includes a picklist field labeled Payroll Time Type, with the values of Scheduled and Actual. This field should be used by 3B to determine which of their products date/time values should populate the custom integration fields. Once populated, these values will be used to update the corresponding Timesheet Entry. As of the publication of this guide, 3B has developed automation to handle the date/time translation process. To implement this functionality, please contact 3B directly to request access to the necessary components and deployment/configuration guides. Break Times 3B WFM supports breaks in Shifts from both the mobile app and Shift records which are captured as a related record called a Break. So that the 2cloudnine 3B WFM Integration can process breaks, a flow (Refer Config Guide) is used to update the relevant break fields (see below) on the Shift record from the related Break records. When a Break is created or updated, the date, time, length and whether it is paid or not is passed to the Shift record. When the Shift record is processed, the break fields are sent to the 2cloudnine Timesheet Entry. Where a Shift contains more than two Breaks, the system will automatically accumulate the additional breaks into the existing break 1 or break 2 based upon if it is paid or not. This is required due to 2cloudnine allowing for a maximum of 2 breaks per Timesheet Entry.
ExampleJohn Smith works a shift commencing 08:00 and finishes at 16:00. During his shift John takes his first break, a 15 minute paid break between 09:00 and 09:15. John then takes a second 60 minute unpaid break from 12:00 to 13:00.
Timesheet Entry with first two breaks captured
John then takes a final third 30 minute unpaid break from 15:00 to 15:30.As both breaks have already been populated from the previous 2 Breaks, the third break is accumulated into the second break, because it is unpaid, whereas the first break is paid.
Timesheet Entry with the third break accumulated into the second
If accumulated breaks are a problem due to the additional breaks being added to the original break, we recommend creating a validation to prevent more than 2 shift Breaks. Should the Employee require more breaks, the scheduler could create a new shift commencing from the required 3rd break.
Paid and Unpaid Breaks 3B WFM and 2cloudnine both support flagging breaks as paid or unpaid. The Break record in 3B WFM contains a checkbox field ‘Paid Break’. When Shift Breaks are created/updated, the system will automatically update the Break 1 Paid or Break 2 Paid field on the Shift based upon this checkbox. Once a Shift is processed, the 2cloudnine 3B WFM Integration will update the Timesheet Entry with the paid break status. The treatment of paid or unpaid breaks in the processing of time is handled by the 2cloudnine Interpretation engine. In the event there are more than 2 Shift Breaks, the system will accumulate the break lengths based upon the paid break flag (see above break times section for more information).

​
Public Holidays

Public Holiday Calendars Whilst Public Holidays are assigned to a single Assignment, the 2cloudnine 3B WFM Integration provides support for flagging Public Holidays at a Timesheet Entry level. When setting up a 3B Job, schedulers must define a default Public Holiday Calendar which will be set on the Assignment when first created. On the Shift record is also a lookup to the Public Holiday Calendar which is defaulted from the 3B Jobe, but can be updated by the scheduler or automation to change the Public Holiday Calendar. When the Shift is processed, the 2cloudnine 3B WFM Integration will use the Public Holiday Calendar defined on the Shift for flagging the Timesheet Entry by checking the field ‘Shift Public Holiday’. During interpretation, the 2cloudnine interpretation engine will only use the Public Holiday Calendar defined on the Assignment . However, because each Timesheet Entry has been flagged or not flagged for a Public Holiday, a report can be utilised to compare the standard ‘IsPublicHoliday’ field and the ‘Shift Public Holiday’ and where discrepancies exist, have payroll amend the pay transactions.
ExampleJohn is placed into a Shift where the related 3B Job has a Public Holiday Calendar set to ‘Victoria’. The Shift record is processed and the Timesheet Entry looks up the related ‘Victoria’ calendar for any public holidays that fall on that day.The next day John works a Shift for the same 3B Job but this time he works in Gippsland in which a public holiday falls. Instead of the scheduler creating an entirely new Job to support this, she simply updates the Shift Public Holiday Calendar to ‘Gippsland’ and processes the Shift.The integration correctly flags the Timesheet Entry as a public holiday and whilst the Interpretation engine will not process the Gippsland public holiday it will be flagged and payroll are then able to update the Pay Transaction to a Public Holiday.If Payroll does not wish to manually update Pay Transactions to accommodate Shift Level Public Holiday Calendars, we recommend updating the ‘AssignmentString’ to also include the ‘Public Holiday Calendar’ from the Shift. This can be achieved by creating an on save flow to set this field using ‘2c9JobRole_Contact_PublicHolidayCalendar’. Just note, if this option is preferred, a new Assignment will be created for each different combination meaning you may also need to consider cross Assignment interpretation.

​
Project Codes & Timesheet Activities

Project Codes & Timesheet Activity on Shifts Project Codes and Timesheet Activities support a variation in an Employees pay whether via an increase in pay rate (e.g. Higher Duties) or via an interpretation variation (e.g. Sleepover). Both Project Codes and Timesheet Activities can be assigned to a 3B WFM Shift and processed via the Integration which are then related to the Timesheet Entry. Schedulers can assign Project Code and Timesheet Activities to a Shift record directly from the Scheduler UI or from the Shift record. When looking up Project Codes and Timesheet Activities from the Shift record only the Template records will be available for selection. As part of the 2cloudnine 3B WFM Integration the template Project Codes and Timesheet Activities related to the Shift will automatically be cloned as Assignment record types, related to the Assignment and subsequently upserted into the Timesheet Entry. Where additional Shifts are processed for the same Assignment, the integration will first check if an existing Project Code/Timesheet Activity. This is done by matching the Assignment level project codes External Id which is set on create to the Shifts>Project Code and Shifts>Timesheet Activity Record Id.

​
Payee Allowances

Payee Allowances - Shift Items Shift Items provide a method for Employees to claim ad hoc allowances related to a Shift record via the ‘Shift Item’ object. Shift Items can then be processed by the 2cloudnine 3B WFM Integration to create related Timesheet Items. Each Shift Item is directly related to a specific shift and uses most of the details from that shift to create a Timesheet Item. However, users can customise some details like the allowance type, quantity, and add any notes they think are relevant. When looking up Allowances from the Shift Item record, only those with a record type of ‘Timesheet Allowance Template Group’ will be available for selection. As part of the 2cloudnine 3B WFM Integration the template Allowance related to the Shift will automatically be cloned as an Assignment record type, related to the Assignment. Once the Payee Allowance has been created on the Assignment, a subsequent Timesheet Item with a record type of ‘Allowance’ is created and related to the matching Payee Allowance and Timesheet period of the Shift. Timesheet Items are related to the Shift record via a Shift lookup and to the Shift Item record via a Shift Item lookup. Where additional Shift Items are processed for the same Assignment, the integration will first check if an existing Payee Allowance exists. This is done by matching the Assignment level Allowance > External Id which is set on creation to the ShiftItem>Allowance> Record Id. The creation and management of Shift Items from the employee experience is not part of the 2cloudnine 3B WFM Integration. This process is typically handled using a custom screenflow which can be embedded into the community and referenced in the 3B WFM app. Shift Item Integration Pending & Sent to Payroll To determine whether Shift Items should be processed by the 2cloudnine 3B WFM Integration, the field ‘Shift Item Integration Pending’ has been added to both the Shift Item and Shift records. For a Shift Item to be processed, this field must be set to TRUE on both the Shift Item and Shift objects. The purpose of having this field on both records is to provide granular level control over when to process Shift Items. Shift Items also contain the Sent to Payroll checkbox, which determines if a related Timesheet Item should be created for the related Shift Item. The flagging of the Shift Item and Shift records to be processed is defined by the customer and updated using a Salesforce flow. The reason for flagging Shift Items at the customer’s discretion ensures each customer can determine their criteria regarding the processing of Shift Item records. The ‘Update Shift on Edit’ flow will need to include the logic to run if the field ‘Shift Item Integration Pending’ is checked. We also strongly recommend this flow updates all related Shift Item records to ‘Shift Item Integration Pending’ TRUE if the related Shift contact or start date is changed. This ensures that if a Shift with related Shift Items is moved to another employee or week, that the integration runs and re-creates the Timesheet Items.

Example 1 - Processing a Shift Item:

A customer specifies that only Shift Items with an Approval Status of ‘Approved’ should be processed. A record-triggered flow is created on the Shift Item object. This flow sets Shift Item Integration Pending and Sent to Payroll to TRUE only when the Shift Item status is approved.An employee submits two Shift Item records for different allowances related to the same Shift. Since they are not yet approved, they are not processed by default. When one of the Shift Items is approved, the flow is triggered, marking both the Shift Item and the Shift for processing.During the 2cloudnine 3B WFM Integration, the system identifies Shift Items marked for processing by checking the ‘Shift Item Integration Pending’ field on the Shift. In this case, it finds only one Shift Item, so it creates only one Timesheet Item. Once the process is complete, the field is unchecked on both records.The same Shift record undergoes multiple integration updates unrelated to Shift Items. Since the ‘Shift Item Integration Pending’ field is not set to TRUE, the system does not unnecessarily process the sameShift Items repeatedly.

Example 2 - Unprocessing a Shift Item:

In the previous example, it’s determined that the ad hoc allowance should not have been processed. The payroll user goes to the Shift Item and unchecks ‘Sent to Payroll’. The flow recognises this change and sets ‘Shift Item Integration Pending’ to TRUE on both the Shift Item and the related Shift.The 2cloudnine 3B WFM Integration runs and deletes the related Timesheet Item records, reversing the processing for the Shift Item.Refer to Timesheet Item - From Shift Item for all 3B WFM to 2cloudnine Timesheet Item mappings.
Payee Allowances - Shift Only Shift Only Payee Allowances provide a way for schedulers to assign a single ad hoc allowance directly to a Shift to be processed by the 2cloudnine 3B WFM Integration. Shift Only allowances are not available to Employees, and are primarily used as scheduler determined allowances only. Schedulers can assign Allowances to a Shift record directly from the Scheduler UI or from the Shift record by populating the Allowance field. By default, Timesheet Items are created with a quantity of 1 and are related to the Shift record via a Shift lookup. The creation and update of the related Assignment Payee Allowance and Timesheet Item uses the same logic as the Shift Item integration. There are only some minor field mapping differences you can find by referring to the Timesheet Item - From Shift mapping. Shift Only allowances were primarily used prior to the introduction of Shift Items which provide greater flexibility (e.g. Multiple claimable allowances, quantities). However as noted, they can still be utilised by schedulers as a way to easily add allowances directly to a Shift from the Scheduler UI, instead of being required to create related Shift Item records. Allowances Only The 2cloudnine 3B WFM Integration also supports the ability for Allowances to be processed against a Shift without creating a Timesheet Entry. This means a Shift can be processed with only the Payee Allowance and subsequent Timesheet Item being created and avoid unnecessary Timesheet Entries. On the Shift record is a checkbox field Allowance Only which if checked will not create a related Timesheet Entry. The field Sent to Payroll must also still be checked to ensure the records are created. Allowance only can be used for both Shift Item and Shift Only based allowances as required.

​
Payee and Payment Entity Selection

Payee and Payment Entity values set on the Assignment, Timesheet and Timesheet Entry can either be defined by the Agreement or the Primary Payee record. Agreement By default, the 2cloudnine 3B WFM Integration will set the Payment Entity on the Assignment using the ‘Default Payment Entity’ field located on the Agreement. The Payee will then be set using matching criteria based upon this Payment Entity. This is particularly useful in customer orgs that contain multiple payment entities in which an Employee can work across and have multiple Payee records. During the creation of the 2cloudnine records, the 2cloudnine 3B WFM Integration will assign the payee based on the following criteria: Payee.Employee = Shift.Employee Payee.Payment Entity = Shift.3BJob.Agreement.Default Payment Entity Payee.Payroll Start Date = Less than or equal to the Shift Date (This means a payee with no payroll start date or a start date in the future will not be used). Payee.Cessation Date = Blank (A payee with a cessation date regardless of date will not be used). Payee.Pay Schedule = IF the pay schedule is defaulted from the Payee (Refer install guide) this is ignored. If however the pay schedule is defaulted from the Account then the Pay Schedule must match the Default Pay Schedule on the 3B Job Role. Where a payee record is not found based upon this criteria, the user who processed the Shift will receive a failed integration email notifying them of the error. It is the responsibility of the user to rectify the issue accordingly. Primary Payee An alternative option is to set the Payment Entity and Payee using the Shift.Contact’s Primary Payee record. Located on the Agreement object is a checkbox field ‘Assignment Primary Payee’ and if this field is selected then both the Payment Entity and Payee will be set from the Shift.Contact’s Primary Payee.

​
Auto Create Payee

The 2cloudnine 3B WFM Integration includes functionality to automatically create a Payee record where one is not found (see above Payee and Payment Entity Selection). To automatically create a Payee record, users can select the checkbox Auto Create Payee on the related Agreement. When the next shift for an Employee is processed and no matching Payee is found, the system will automatically create the Payee record and relate it to the Assignment and Timesheet. It is important to note a Payee record will be created every time a Payee record is not found. For example, if ‘Assignment Primary Payee’ is unchecked, then a new Payee record will be created every time an Employee is placed in a Shift for a different Payment Entity. Only the Payee record is created by the 2cloudnine 3B WFM Integration. Any Payee Withholdings and Payment Details must be created separately either from your standard payroll onboarding process or manually from payroll.

​
Rate Calculator

The 2cloudnine 3B WFM Integration has been specifically designed to utilise the 2cloudnine Rate Calculator for the creation and management of Assignment Rates. Located on the 3B Job record is a lookup to the Rate Calculator object filtered by a record type of Template. When a scheduler creates a Job Role, they must select a Rate Calculator template. In addition to the Rate Calculator lookup are fields Rate Calculator Template Group, Award Classification, Award Level, Location, Industry, Risk Classification and Inherit Rate Calculator Values From. These are optional fields that can be used as defaults when the Rate Calculator does not contain these fields populated. When the first Shift for a new Job Role is processed, the integration will assign the Rate Calculator template to a lookup on the Assignment labelled Rate Calculator Template. A scheduled job (refer config guide) will run and automatically create the Employee Specific Rate Calculator and assign it to the Assignment. Where any subsequent Shifts are processed with the same AssignmentString, the system will check if the 3B Job > Rate Calculator is the same as the Assignment > Rate Calculator Template. If different, the integration will update the Assignment > Rate Calculator Template with the Rate Calculator defined on the Job Role. If the field Inherit Rate Calculator Values From on the Job was set to Assignment the Award Classification, Award Level, Location, Industry and Risk Classification set on the Job Role will be used on the Employee Specific Rate Calculator. To provide greater flexibility where an Employee may work across different Classifications, Levels, Locations, Industry and Risk Classifications under the same Job, the Award Classification, Award Level, Location, Industry and Risk Classification are also on the Shift record. These are also optional fields that can be set on the Shift record and will be updated on the Assignment by each processed shift. Where both the 3B Job and a Shift contain these fields populated, the 2cloudnine 3B WFM Integration will use the values from the Shift. For detailed instructions related to the setup, configuration and management of the Rate Calculator, please refer to the Rate Calculator User Guide.
ExampleAs a scheduler, Kylie creates a new 3B Joband selects the SCHADS Interpretation Rule and SCHADS Rate Calculator Template. Kylie then creates a Shift and sets an, Award Classification, Award Level, Location, Industry and Risk Classification.Kylie processes the Shift and an Assignment is created inheriting the Schads Rate Calculator Template from the 3B Job and the Award Classification, Award Level, Location, Industry and Risk Classification from the Shift.The admin who manages the company Org has configured the Rate Calculator to automatically create and inherit values from the Assignment. As the Assignment is created a new Employee Specific Rate Calculator is created and Assignment Rates are instantly generated ready to process the Timesheet with the required rates.
Rate Calculator Template Group As noted above, the 3B Job includes a filtered lookup to the Template object > Rate Calculator Template Group. This lookup is used to populate a Rate Calculator Template Group, which is required when customers are utilising the Minimum Pay Rate (MPR) functionality. Currently, the 2cloudnine Assignment object does not include a lookup to the Rate Calculator Template Group. As a result, when an Assignment is created via the 2cloudnine 3B WFM Integration, it is unable to populate this field. This limitation also prevents any subsequently created Employee Specific Rate Calculator from automatically referencing the correct template via its ‘Minimum Pay Rate Template’ lookup field. To work around this limitation, orgs that require the Rate Calculator Template to be inherited into Employee Specific Rate Calculators must implement a record-triggered flow. This flow should run on Create of an Employee-Specific Rate Calculator, and should:
  1. Retrieve the Rate Calculator Template Group via the following relationship chain:
    1. Rate Calculator → Assignment → 3B Job → Rate Calculator Template Group.
  2. Populate the retrieved value into the Rate Calculator’s ‘Minimum Pay Rate Template’ lookup.

​
Approving/Processing Timesheets

All Timesheet and Timesheet Entry records by the 2cloudnine 3B WFM Integration have an Approval Status of ‘New’. In order for a Timesheet to be processed by the 2cloudnine Interpretation engine, the Timesheet and related Timesheet Entries must be updated to a status of Approved. The approving and processing of Timesheets is not a function of the 2cloudnine 3B WFM Integration and must be controlled by the customer in-line with their approval requirements. Options could include having all Timesheets updated with an Approval Status of ‘Submitted’ and have clients login to the 2cloudnine Approval portal and approve the timesheets as is the most common workflow in 2cloudnine. Alternatively, if it is assumed that 3B WFM Shift records are already approved by a client, creating an automated process to approve timesheets each week could be utilised.

​
Error Handling

The 2cloudnine 3B WFM Integration includes two methods of Error Handling: Email Notification The user who invokes the ‘ShiftAssignmentBatch’ apex class will receive an email notification when an error occurs within the batch job. For the scheduled batch class, this will be the user who scheduled the batch job (typically the admin account). Where the class is invoked from another process such as a screenflow, this will be the user who invoked the class. Debug Logs Where the integration fails, a Debug Header and related Debug Logs are created. A single Debug Header is created per processed Batch, with related Debug Logs for each individual failed Shift. For example if a batch contained 30 Shifts, and within that batch, 3 failed, there would be a single Debug Header record with 3 related Debug Logs for the 3 failed Shifts.

​
Timesheet Adjustments

11 Timesheet Adjustments allows for 3B WFM Shift records to be updated and processed regardless of the related Timesheet’s Approval and Processing status. When a Shift is updated and processed by the 2cloudnine 3B WFM Integration it will check the Timesheet Status and if it is ‘Approved’ it will flag it for adjustment by updating the checkbox field ‘schedulejobprocessed’ to TRUE. Due to Timesheet Adjustments not being part of the 2cloudnine 3B WFM Integration package, a custom checkbox field ‘Integration Pending’ is used and must be updated via a custom flow to ensure its value matches that of the ‘schedulejobprocessed’ field and vice versa. All Timesheet records where this checkbox is checked will be automatically scheduled to be adjusted when the next batch job is scheduled to run. The timing of the scheduled batch job is defined by your system administrator as part of the installation and setup of Timesheet Adjustments. It is highly recommended to schedule the Timesheet Adjustment batch to run approximately 1 minute after the Shift integration. Timesheet Adjustment Where a Timesheet has an Approval Status of ‘Approved’, it will be automatically reverted to ‘New’ by the Timesheet Adjustment process regardless if Transactions have been processed and subsequently payrolled or invoiced. Once a timesheet has been reverted to ‘New’ it will need to go through the approval process again in order for it to be processed by the interpretation engine. Pay Transaction Adjustments Where a Timesheet has been ‘Approved’ and transactions have been processed, the Timesheet adjustment process will loop through the related Pay Transactions and check if any of them have been paid and/or invoiced. If Pay Transactions have not been paid and/or invoiced, they will be automatically deleted and with the Timesheet reverted to New and Timesheet Entry updated, can be processed again with the updated Interpretation. If Pay Transactions have been paid and/or invoiced they cannot be deleted due to data integrity and are instead unrelated from the Timesheet. These Pay Transactions are then cloned and updated with a negative quantity and unrelated to the paybatch and/or invoice item of the original transaction. Both the cloned Pay Transactions and original Pay Transactions are unrelated to the Timesheet, however the original Pay Transactions are related back to the Timesheet via a custom lookup ‘Reversed from Timesheet’. This can then be added as a related list to the Timesheet so someone viewing a Timesheet record can see any transactions that have been reversed. Once the Pay Transactions have been cloned and reversed, the Timesheet will again be reverted to ‘New’ and will need to go through the approval process in order for it to be processed by the interpretation engine. When a PayBatch or Invoice is created the reversed transactions and if applicable newly created transactions will be available to be picked up and processed by 2cloudnine.
ExampleJohn is assigned to a single shift with a ‘Pay Scheduled Time’ of 09:00 to 16:00.This Shift is processed by the 2cloudnine 3B WFM Integration and creates the subsequent Assignment, Timesheet and Timesheet Entry.This Timesheet is then approved and processed by the Interpretation Engine which creates a single Ordinary Time Pay Transaction with a quantity of 7 with a pay rate of $50 as per his related Assignment Rate.John is paid for this shift in the Weekly pay run but realises the quantity is incorrect because he wasasked to work from 09:00 to 18:00 as per his clocked actual time in 3B WFM.The scheduler, aware of the mistake, goes into the 3B WFM shift and unchecks the Pay Scheduled Time so the integration will use the Actual Time and processes the Shift which flags the Timesheet for adjustment.When the Timesheet Adjustment is triggered the Timesheet is reverted to ‘New’ and the Timesheet Entry is updated from 09:00 to 18:00. The existing Pay Transaction is removed from the Timesheet and cloned to create a Transaction with a quantity of -7 and a pay rate of -$350.The Timesheet is again approved and processed which now creates an ‘Ordinary Time’ Pay Transaction with a quantity of 8 and because he went into overtime for 1 hour an Overtime 1.5 Pay Transaction with a quantity of 1 and Pay Rate of $75.John is payrolled again for his adjusted Timesheet and the Paybatch brings in both his reversed and newly processed transactions, which results in a net positive of 1 hour ‘Ordinary Time’ and 1 hour ‘Overtime 1.5’. John receives a payment of $125 pre tax.In the example, the Scheduler was able to make the change to the Shift without any consideration of the back office. Likewise, the back office was able to process the payroll as per normal. This workflow may not however work for all organisations and they may wish to control this process by either enforcing validation to prevent changes to paid Shifts or ensuring checking is in place prior to paying adjusted Timesheets.
Timesheet Item (Allowance) Adjustments Timesheet Items (Allowances) created by the 2cloudnine 3B WFM Integration are also updated by the Timesheet Adjustment process to clear the value of ‘Date Pay Transaction Generated’ from all Timesheet Items related to that Timesheet. This is required to ensure the Timesheet Items can be processed again without error. The pay transactions generated from Timesheet Items are handled by the Pay Transaction adjustment as per above. In the event an Allowance was removed from a Shift after being paid/invoiced, the Timesheet Item will still be deleted, and the Pay Transaction reversed as per normal. Overlapping Times Validation Shifts that are processed with an overlapping time are allowed except where the Timesheet has a status of ’Approved’. Where a processed Shift attempts to insert an overlapping Timesheet Entry, a system validation will fire and cause the insert to fail. When this occurs, the Shifts ‘Interpretation Pending’ will remain checked and be picked up for processing again in the next scheduled batch job. In this scenario, the Timesheet Adjustment process will still however trigger for the incoming Timesheet, causing it to revert to New. This means the next time the Shift is processed, the validation will no longer fire as the Timesheet has a status of ‘New’.

​
Object and Field Mappings

Assignment
  • Refer the Installation and Setup guide for more information about Pay Schedule defaults.
Rate Calculator Templates are only updated when the Shift>3BJ ob>Rate Calculator !=Assignment>Rate Calculator Template Timesheet Timesheet Entry
  • The Payee Allowance Record is a clone of the related template allowance assigned to the Shift. See above section on Allowances.
  • The Payee Allowance Record is a clone of the related template allowance assigned to the Shift. See above section on Allowances.
Payee Pay Advice Template selected where Pay Advice Template.Payment Entity = Contract.Default Payment Entity and name contains ‘PAYG’. If no template is found then integration selects Pay Advice Template where ‘Default’ is True. Document prepared by: Ben Albani