Contents
What data is synced from Time & Attendance to Auto-Rostering?
Updated
by Kellie Oxley
Time & Attendance to Auto-Rostering
Provisioning and Synchronising
When you first run the setup wizard, the system connects Time & Attendance with Auto-Rostering and performs an initial transfer of data—this is called provisioning. It’s a one-time setup to get everything started.
After this, any changes made in Time & Attendance that need to update Auto-Rostering are part of the ongoing synchronisation process.
Some data fields are only included during that first provisioning step and aren’t updated later during normal synchronisation. This document explains which fields fall into that category, so you know what to expect.
Employees
When you select an employee in the Time & Attendance Auto-Rostering setup wizard, they’re added to Auto-Rostering as part of the provisioning process.
From there, key details about each employee are kept up to date through synchronisation with Time & Attendance. The list below shows exactly which data is synchronised.
T&A entity | Events | Comments |
Employee | Created Updated Deleted | Deleting an employee is a permanent action—once removed, their profile is deleted from both Time & Attendance and Auto-Rostering. This process is known as a hard delete, meaning the data cannot be recovered. |
Contract | Updated | For example, an employee has a leave date entered in Time &Attendance |
Organisation | Updated | An example would be where an employee changes to a different team in Time & Attendance |
Job Details | Updated | For example an employee receives a promotion and their job title is changed |
Lookup Data
In Time & Attendance, a lookup refers to a dropdown list that helps users select consistent options when updating employee details. For example, when assigning a department to an employee, users pick from a predefined list—this helps avoid typos and ensures data stays uniform across the system.
During the initial setup, several of these lookups are provisioned (transferred to Auto-Rostering), and they continue to be synchronised during everyday use to keep everything up to date.
The following table describes which lookups are provisioned and synchronised
T&A lookup | T&A Database field | Rostering field | Events | Comments |
LOCATION | LUORG.CODE LUORG.DESCRIPTION | Location | Create Update Delete | The LOCATION lookup is provisioned during setup and synchronised in day to day operations |
DEPARTMENT | LUORG.CODE LUORG.DESCRIPTION | Department | Create Update Delete | The DEPARTMENT lookup is provisioned during setup and synchronised in day to day operations |
COSTCODE | LUORG.CODE LUORG.DESCRIPTION | Cost code | Create Update Delete | The COSTCODE lookup is provisioned during setup and synchronised in day to day operations |
DIVISION | LUORG.CODE LUORG.DESCRIPTION | Division | Create Update Delete | The DIVISION lookup is provisioned during setup and synchronised in day to day operations |
JOBTITLE | LUORG.CODE LUORG.DESCRIPTION | Job Title | Create Update Delete | The JOBTITLE lookup is provisioned during setup and synchronised in day to day operations |
Employee details
Some specific data fields are both provisioned during the initial setup and synchronised regularly between Time & Attendance and Auto-Rostering to keep everything aligned.
These fields are listed below. In the table, you’ll notice that fields from the Time & Attendance database are shown using the format [tablename].[fieldname]. This simply reflects the table name and the columns in the tables.
Short Table Name | Table Description |
TMSEMP | Time & Attendance Employee Details Personal employee information, such as first name, surname |
OD | Organisation Details Data such as location, department, division |
CE | Contract and Entitlements Data such as start date, weekly hours |
JD | Job Details Data such as job title |
T&A entity | Rostering Field | T&A Database field | Comments |
Employee | Employee No | TMSEMP.EMPREF | Required, unique |
Employee | First Name | TMSEMP.FIRSTNAMES | Required |
Employee | Last Name | TMSEMP.SURNAME | Required |
Employee | TMSEMP.EMAIL | Required, unique | |
Contract | Start Date | CE.STARTDATE | Required, must be before leave date |
Contract | Leave Date | CE.LEAVEDATE | |
Organisation | Location | OD.LOCATION | |
Job Details | Department | JD.JOBTITLE | Job Titles linked via the "Use Job Titles" HR system preference are not supported. |
Contract | Weekly Hours | CE.WEEKLYHOURS |
Absence Codes
Every T&A absence code is provisioned to Auto-Rostering.
T&A entity | Rostering Field | T&A Database field | Comments |
Absence Code | Name | TMSAC.CODE | Required, unique |
Absence Code | Colour | TMSAC.COLOUR | Hardcoded as #dc4405 (red-orange) |
Employee Absences
All authorised employee requests for absences are staged in a table called TMSFC (TMS Future Changes). The following table describes the relationship between the fields in this table and the corresponding fields in Auto-Rostering.
T&A entity | Rostering Field | Event | T&A Database field | Comments |
Employee planned absence | Absence Code | Create Delete | TMSFC.CODE | Required |
Employee planned absence | Absence Start | Create Delete | TMSFC.STARTDATE | Required |
Employee planned absence | Absence Start Time | Create Delete | TMSFC.STARTTIME | This field is only required if the "Process Absence on non-working days" is set in the T&A system preferences, and the employee books an absence where there is no shift planned |
Employee planned absence | Absence End | Create Delete | TMSFC.ENDDATE | Required |
Employee planned absence | Absence End Time | Create Delete | TMSFC.ENDTIME | This field is only required if the "Process Absence on non-working days" is set in the T&A system preferences, and the employee books an absence where there is no shift planned |
Employee planned absence | Absence Hours | Create Delete | TMSFC.HOURS | This field is only required if the employee has requested an absence other than a full day (e.g. first or second half of shift) |
This ensures the most recent information is always reflected accurately,
In Time & Attendance, there are two types of absences:
- Employee-specific absences — these apply to individual team members
- General absences — these apply to multiple employees, such as Public Holidays, Factory Shutdowns, or similar events
The table below shows which general absence fields are included during the setup (provisioning) process. Keep in mind: these fields are not updated during normal daily synchronisation.
T&A entity | Rostering Field | T&A Database field | Comments |
General absence | Absence Code | TMSGNABS.HRSCODE | Required |
General absence | Absence Start | TMSGNABS.STARTDATE | Required |
General absence | Absence End | TMSGNABS.ENDDATE | Required |
General absence | Absence Hours | TMSGNABS.HOURS |
Skill Codes
Auto-Rostering works most effectively when each job in the system includes a list of required skills. This allows the system to automatically assign the best-suited employees to each task, helping you plan more efficiently.
Skills are created and managed in Time & Attendance, and they’re transferred to Auto-Rostering during the initial provisioning setup. After that, they continue to be synchronised during everyday operations to keep your staffing data up to date.
T&A entity | Rostering Field | Events | T&A Database field | Comments |
Skill Code | Name | Create Update Delete | TMSCSKLL.CODE | Required, Unique |
Skill Code | Description | Create Update Delete | TMSCSKLL.DESCRIP |
Employee Skills
After you’ve defined your list of skills in Time & Attendance, the next step is to assign those skills to each relevant employee.
Once that’s done, each employee’s skill set is automatically provisioned to Auto-Rostering during setup, and then continuously synchronised in everyday use. This ensures you — or the system’s built-in auto-solver — can always select the right people for the right jobs, based on their skills.
T&A entity | Rostering Field | Events | T&A Database field | Comments |
Employee Skill | Skill Code | Created Deleted | TMSEMPSK.CODE | Required |
Sometimes, the skills recorded in Time & Attendance are linked with relevant qualification or training records—adding extra detail to an employee’s profile.
When this happens, those qualification and training records are included during the initial provisioning into Auto-Rostering, but they are not synchronised during everyday use. So if a qualification changes in Time & Attendance, it won’t automatically update in Auto-Rostering.
The tables below show how qualifications and skills are mapped between the two systems.
T&A entity | Rostering Field | T&A Database field | Comments |
Employee Qualification | Skill Code | QUAL. * |
From T&A training record (dependent on configuration) the following are provisioned:
All Employee-training-record are provisioned
T&A entity | Rostering Field | T&A Database field | Comments |
Employee-training-record | Skill Code | TR.* | [Skill Code entity mapping] |
Shifts (shift definitions)
In Time & Attendance, shifts are organised into two types:
- Named shifts — standard shift patterns that are shared across employees
- Personalised shifts — custom shift setups tailored to individual employees
Named shifts are both provisioned during setup and synchronised with Auto-Rostering during everyday use. Personalised shifts, however, are not included in this synchronisation process.
Since personalised shifts don’t appear in the list of named shifts, this won’t affect your normal Auto-Rostering operations.
T&A entity | Rostering Field | Events | T&A Database field | Comments |
Shift | Group | Create Update Delete | - | This is not a field in T&A, it is a convenient way of labelling shifts that have been synchronised from T&A in Auto-Rostering. It is hardcode with the name "TMS" |
Shift | Code | Create Update Delete | TMSWS.RREF | Required |
Shift | Description | Create Update Delete | TMSWS.DESCRIP | |
Shift | Start Time | Create Update Delete | TMSWS.STARTDAY | Required. No time zone offset applied |
Shift | End Time | Create Update Delete | TMSWS.ENDDAY | Required. No time zone offset applied |
Shift | Hours | Create Update Delete | TMSWS.STDHOURS | Required |
Auto-Rostering to Time & Attendance
Until now, we’ve focused on how information flows from Time & Attendance to Auto-Rostering, through provisioning and synchronisation.
While no data is provisioned from Auto-Rostering back into Time & Attendance during setup, certain updates do happen in the opposite direction. The details below highlight what information is synchronised from Auto-Rostering to Time & Attendance during specific events — helping to keep both systems aligned as your workforce plans evolve.
Rostering entity | Event | Example | Comments |
Schedule publish | Created | User selects 'Publish' for date range within a schedule | Created event is triggered and schedule sync request is created with state 'Pending' |
Created Event:
- When an Auto-Rostering schedule is published, any planned shifts that were previously created for that same schedule — and fall within the selected publish date range — are removed from Time & Attendance.
This ensures that the most up-to-date schedule from Auto-Rostering takes priority, and avoids any confusion caused by overlapping or outdated shift information. - For each job assignment in the Schedule publish;
- An employee planned shift (read-only) is created in T&A and every field in the relevant Field mapping table is populated.
- An error is logged if the planned shift cannot be created in T&A.
- An info message is logged if the planned shift is successfully created in T&A.
- If a ‘Rostered job’ TAS category (unvalidated type) is defined for ‘Job Type’, then a planned rostered job is created for the duration of the Shift
- For each custom data value for the job;
- Custom TAS data is added to the planned shift in T&A
- An error is logged if the rostered job, or custom data cannot be created in T&A.
- Result is sent back to Auto-Rostering containing;
- The status of the Schedule publish - 'Success' or 'Error'.
- A message for each job assignment with status 'Error' including a message
Schedule publish (Job assignments)
When a schedule is published in Auto-Rostering, the associated job details and planned shifts are automatically synchronised with the Time & Attendance system.
This update uses the same staging table (TMSFC) that's also used for absence data—but with a different change type to indicate that it's a shift change, not an absence.
The table below shows how information is mapped between Auto-Rostering and Time & Attendance during the publishing process, where are predefined named shift has been selected.
Rostering field | T&A entity | T&A BD field | Comments |
Employee | Employee Planned Shift | TMSFC.EMPREF | |
Shift | Employee Planned Shift | TMSFC.CODE | |
Start Date | Employee Planned Shift | TMSFC.STARTDATE |
In Auto-Rostering, you’re not limited to using only named shifts. You can also create jobs based on specific start and end times, without linking them to a predefined shift pattern.
When a schedule containing these timed jobs is published, the job and shift details are synchronised with Time & Attendance. Unlike named shifts— which already exist in the shift table—these timed shifts are created automatically during synchronisation and stored quietly in the shift table, without appearing in the named shift list.
These timed shifts are then stored alongside named shifts in TMSFC as we saw earlier. Should you ever look at the planned shift changes in T&A for an employee these timed shifts can be spotted easily - they all begin with an exclamation mark.
Rostering field | T&A entity | T&A BD field | Comments |
- | Shift (personalised) | TMSWS.REF | Generated automatically by the system |
Start Time | Shift (personalised) | TMSWS.STARTDAY | |
End Time | Shift (personalised) | TMSWS.ENDDAY | |
Hours | Shift (personalised) | TMSWS.STDHOURS | |
Employee | Employee planned shift | TMSFC.EMPREF | |
- | Employee planned shift | TMSFC.CODE | The code matches the automatically generated shift as described above |
Start Date | Employee planned shift | TMSFC.STARTDATE |
If you’ve set up Auto-Rostering to link Job Type to a specific field in the Time & Attendance system (this is configured during the initial setup and provisioning), then extra details will be written into the rostered jobs table (TMSWSJOBS) in Time & Attendance whenever a schedule is published.
This helps ensure job information is accurately recorded and aligned across both systems.
Rostering field | T&A entity | T&A BD field | Comments |
- | Rostered job | TMSWSJOBS.EMPREF | As per TMSFC.EMPREF for employees planned shift |
- | Rostered job | TMSWSJOBS.WSREF | As per TMSFC.CODE for employees planned shift |
- | Rostered job | TMSWSJOBS.WSDATE | As per TMSFC.STARTDATE for employees planned shift |
- | Rostered job | TMSWSJOBS.TASCODE | If you’ve selected a TAS category in the 'rostered jobs' configuration during the Auto-Rostering setup wizard, that category will be linked to the Job Type field |
Job Type | Rostered job | TMSWSJOBS.TASVALUE | Text description of Job Type from Auto-Rostering |
If you’ve chosen to link custom data in Auto-Rostering to your existing Time & Attendance (TAS) setup, then the custom fields you’ve mapped will also be synchronised. This means any mapped custom data will be kept up to date across both systems during normal operations.
The table below outlines which custom fields are included and how they relate between Auto-Rostering and Time & Attendance.
Rostering field | T&A entity | T&A BD field | Comments |
- | Rostered job | TMSWSJOBS.EMPREF | As per TMSFC.EMPREF for employees planned shift |
- | Rostered job | TMSWSJOBS.WSREF | As per TMSFC.CODE for employees planned shift |
- | Rostered job | TMSWSJOBS.WSDATE | As per TMSFC.STARTDATE for employees planned shift |
Custom data type | Rostered job | TMSWSJOBS.TASCODE | Mapped to TAS category with matching lookup from Time & Attendance 'rostered jobs' configuration. Configured during the Auto-Rostering setup wizard |