Why You Can’t Import into Historical Fields in Bob, and What to Do Instead

Hi Sara, I just want to confirm that if we switch a field to Historic field, the data that’s already in there will be unaffected? Would the effective date become the date of the switch, or when the field was updated to the current value?

Hi ​@dschorr 

Yes, correct, if you switch a field to Historical, the data that’s already in the field will remain intact and won’t be deleted. The effective date will be the date the field value was last updated by a user or via import, and not the date you switch the field to Historical. 

I hope this clarifies, thank you 😊

> There’s currently no feature that combines the best of both—but our Product team is aware of the need and it’s on their radar.

🙏 please.

Our use case: we use historical field  to keep track of a bonus; That bonus resets yearly, so every year, we need to update all the employees manually. Annoying.

Hi ​@Olivier Tassinari - thank you for the follow up 🙏🏻

In this case, the best practice would be to use the Variable Pay table under the Payroll category instead of a historical field.

This allows you to add a row per year, specify the relevant year for each entry, define the grant type as Bonus, and then generate the relevant reports based on that data. It’s much more scalable for annual bonus updates and avoids the need for manual changes employee by employee.

​@Netta Brodsky Those bonuses are small budgets are for company expenses employees can tap into, not salary, so variable pay won’t work.

Hi ​@Olivier Tassinari - Thanks for the clarification 😊

In this case, one option is to create a custom field (not set as Historical), perform the import to populate the data, and only then switch the field to Historical. Just keep in mind that once the field is defined as Historical, any future updates will need to be done manually.

Another alternative is to use a custom table and import the data there instead, which gives you more flexibility for ongoing updates.

​@Netta Brodsky Yes, this is the problem. We use the historical field to keep this clearly organized, once a year, we reset the balances, because we can't mass important, we have to do it manually.

One day, I will want to vibe code an HRIS and fix this on my own 😁. 

Thank you for clarification - ​@Olivier Tassinari 

In this case, the most practical approach would be to use a custom table. Tables support bulk imports and naturally keep historical data, so you can reset or update the balances once a year without needing to do everything manually.

A common setup is to have one column for the effective date/year and another for the value itself, which keeps things both structured and reportable over time.

​@Netta Brodsky Would it be possible to allow us to create a table which follows the same pattern as Bob default tables which have the most recent date as the one being in effect? That would make it much simpler for everyone.

Adding that I would also appreciate if we could have any custom data fields that can be all of the below:

• updated via mass import
• used to group or split via x axis in dashboards
• be time bound

Is it true that there is no one field that can accomplish both? 

Our use case is to save additional performance data and programmatic data about our talent program registration so that we can track over time, but there’s too much data to update one by one. 

It’s unfortunate that Bob is such a flexible solution in some ways, but has limits in place where it could provide the strongest strategic value. 

Our workaround for now is that we have to add new ‘labelled’ data as new values each time we run a new cycle, but I can’t see this being a scalable solution. 

I would also greatly appreciate if Site Country, Site State/Province etc. could be reportable in Dashboards!