Contrary to what it might look like from my last few blog posts, the past few months have not been completely wrapped up in Tornado Survivor Mode! It has been a busy few months at work as well. We acquired a new company and incorporated the new Employees and their entire CRM/PSA/Accounting data into our systems, we have furiously worked on all the normal corporate shifts and changes for a new Fiscal Year and we designed, built and launched a new PTO Tracking System for our Employees!
This post will walk you through the need behind the PTO Tracking System and how we put it together. Hope it helps you think outside the box at how you can leverage the Salesforce Platform to meet the needs in your organization!
When I first started a few years ago we had less than 100 employees in 2 countries. Now we are closing in on 500 employees across multiple continents. What used to work for PTO tracking (using our payroll system) is no longer a good option. We log timecards using the FinancialForce PSA, but that wasn’t linked to any sort of PTO System. Our payroll department would pull reports on the 15th of each month for the previous month of time logged to PTO and load those numbers in the Payroll system so the balances would show up on paystubs. Now think about that timing. You log vacation on the 2nd of the month, and it doesn’t debit from your available balance for almost 45 days. The lag was just getting to be too much. Nowadays no-one gets paper pay stubs, so it was yet another system to log into to check your (hopelessly out of date) balance. And this tool was only for US employees – there were other systems for employees in other countries and some were even tracked via <gasp> spreadsheet.
Now, FinancialForce has a solution for PTO in their HCM product. And we have looked hard at it. Since we currently use the FinancialForce PSA and Accounting Applications as well as various add-ons, it would make sense to go with the HCM tool. But a full-on HCM implementation is not a small undertaking. Our org currently has 360+ custom objects and the HCM package is well over 200 more. I am part of a 2-admin team serving almost 500 users on an end-to-end Company tool and without significant time and extra bodies, an HCM implementation is not an option for right now. Not to say we won’t go that route eventually. In fact I’d say we’ll likely get there, but in the meantime, we had a problem and needed a solution.
We needed to be able to provide a real-time balance to each employee, we needed a central repository for what our PTO policies are, a way for managers to quickly see the rules for his/her employees along with current balance information and a link to the timecard process that everyone is required to use anyway.
Employee: This object is Private to Owner but shared with Admins/HR Groups. Owner is Manager of Employee. This record houses HR data, information about system access, licensing & equipment assigned to the Employee.
PSA Resource: This is a record type of the standard Contact Object used by the FInancialForce PSA system extensively. The Resource record represents the User who is assigned to projects for time and expense logging and doing ‘work’. Every user who logs time has a Resource Record – the timecards are linked to those records.
PTO Standard Rules: This object is visible by HR/Admins. These records make up our Standard Rules sets. Typically each country we have employees in has different PTO criteria, and each country has a Full-Time/Part-Time rule as well. We capture how many hours are accrued per period and if they are designated as Vacation, Sick or simply PTO. We capture any ‘Cap’ information (the maximum amount of PTO someone can hold at any given time) and yearly Roll-Over information. Going through the process of capturing this info was slightly painful, but necessary – my company has grown quickly over the past few years and this information wasn’t centrally maintained. Once we determined all the Rules, our HR department went back through all contract agreements and ‘assigned’ each Employee to the PTO Standard Rule set they fall under (this is simply a lookup on the Employee Record to the PTO Standard Rule).
PTO Summary: This is a custom object created to keep track of total Accrual amounts. The object is Private to Owner but shared with Admins/HR Groups and shared hierarchically. The Owner is the actual User. We use Roll-up Summaries of the PTO Accrual Line Items to display the current PTO Balances. There are also fields to display the CAPs for the Employee (if any) and a checkbox that gets checked via a process when the Total PTO exceeds the CAP – this is used later to debit hours if the CAP is exceeded. The PTO Summary is created via a Process when the User Record is created. It is then linked to the PSA Resource record via a lookup on that object. This links the Resource and PTO Summary so when time is logged we can easily ‘get to’ the PTO Summary for that Resource to create a PTO Accrual Line Item.
PTO Rules: This is a custom child object to the PTO Summary Record. This holds the Employee Specific PTO Rules and date ranges. Our company has 4 main timeframes for PTO increases (0-4 yrs, 5-9 yrs, 10-14 yrs, 15+ yrs). When the PTO Summary is created, a process creates the 4 Employee Specific Rules with the appropriate date ranges. It looks at the related Employee Record to see which PTO Standard Rule should be followed, then creates lines for each time frame – there is a start/end date for each Rule that is calculated from the Employee Start Date. The PTO Rule contains the number of hours for Vacation/Sick that the Employee Accrues for each pay period within a specific time frame. HR has access to manually edit and add notes to specific rules in the event an employee has an exception written into their contract. There is also a formula field on each rule that checks to see if (based on the dates of the rule) the rule is active – if so, a checkbox shows as true – so we always know which rule is active at any given time.
PTO Accrual Line Items: This is a custom child object to the PTO Summary Record. These are the line items that make up each individual Accrual/Debit of PTO. There are fields to capture the type of accrual (beginning balance, accrual, debit, adjustment), the amount accrued (positive for an accrual, negative for a debit), the type of accrual (Vacation/Sick), notes and a link to the timecard if the line is related to a debit. I’ll go into more detail below about how these are created. HR provided a beginning balance for each employee through a specific date and those were loaded into the system. These line items are then summed via Roll-Up Summaries on the related PTO Summary Record to show Balance information.
Projects/Milestones: These are standard FinancialForce PSA objects. We created PTO Projects for each Country (since they have different holidays/time off periods allowed) and Milestones to represent those buckets. Examples of the milestones are ‘Vacation’, ‘Sick’, ‘Jury Duty’, ‘Force Majeure’, etc. On the Vacation and Sick Milestones I have a PTO Type picklist I have set – this tells the system (if time is logged against this milestone) which type of PTO Accrual Line Item to create.
Timecards: Every Employee logs timecards each week. When an employee logs time against the PTO Project and either the Vacation or Sick Milestone, the timecard is sent to the User’s Manager for Approval. Upon Approval of the timecard, a Process looks at the related Resource record to find the appropriate PTO Summary Record and creates a new PTO Accrual Line Item to debit the PTO balance of that Employee for the number of approved hours. The PTO Accrual Line Item includes a link to the timecard for review purposes as necessary.
HR creates Employee Record for new hires, when complete and ready to onboard, sends notice to admin to onboard. (Emp Record has lookup to the PTO Standard Rule this Employee was hired under – this is filled out by HR.)
Admin kicks off Process to create Resource Record & User Record. Underlying Process creates PTO Summary, Employee Specific PTO Rules & links Summary back to Resource Record & User Record. Admin then assigns new User to Appropriate PTO Project for time logging.
For Regular Accruals: Our pay periods are the 15th and the end of the month. Our PTO Standard Rules are typically set to Accrue for each prior pay period. So on the 16th and the 1st of the month I would accrue hours for the prior period.
Currently, as we are kicking off the new system, I am manually processing the accrual records. I run a report on the 15th and last day of the month that shows each active employee and his/her currently active rule. I then use the data loader to create PTO Accrual Line Items to Accrue time. The manual process is allowing my HR Team and users to ‘get comfortable’ with the accuracy of the data. My next step will be to create an automated process to accrue PTO twice a month.
In addition, there is a workflow setup to check a box on the PTO Summary when the balance exceeds any CAP that might be specified on that Standard Rule (example, some rules have a max of 160 Vacation hours – so if an employee accrues time and the sum of vacation exceeds 160 a box is checked). When that box gets checked, a process kicks off that creates an ‘Adjustment’ PTO Accrual Line Item to debit the vacation hours back down to the CAP. It is all very visible to the Employee so they can see when they are losing hours accrued because they aren’t taking time off. (Time off is important!) When the Employee gets within 10% of his/her CAP, an email goes out to the employee to remind them they are getting close to their CAP and should consider taking some time off.
The benefits of the new System are that the accruals/debits/adjustments are all clearly visible to the Employee and Manager. An Employee can see their specific Rules at any given time. Managers have reports setup so they can review the balances regularly and before approving timecards submitted. HR can make changes to the Rules as necessary when contracts/agreements change and (again) it is all visible to the employee and transparent. Payroll can simply run a report of all of the debits from timecards for hourly employees and load those straight into the payroll system. It has been well-received by all involved!
This was such a fun project to work on. Maddening at times trying to get the right information from the right sources, but it was challenging and represented a very visible solution for all involved!