Skip to main content
On 1 August 2026, absentify replaced fixed yearly allowance amounts with reusable allowance rules. If your workspace already existed before that date, absentify converted your data for you. This page explains what changed, what did not, and what is worth a quick look.
Workspaces created on or after 1 August 2026 start with allowance rules from day one and were never converted. If that is your workspace, you can skip this page and read Allowances settings instead.

What happened

Until now, an allowance was a plain number. For every employee and every year, someone typed in how many days or hours that person was entitled to. Carry-over limits and expiry were configured once for the whole allowance type, and every exception had to be typed in by hand. Allowances are now defined by allowance rules. A rule describes how much is granted, in which cycle, when the allowance year begins, and what happens to unused allowance. One rule can be assigned to many employees, and an employee is assigned exactly one rule per allowance type at any point in time. absentify converted the existing data automatically. You did not have to do anything, no configuration was lost, and no one had to re-enter numbers.

What did not change

This is the important part: every balance stayed exactly as it was.
The remaining balance of every employee is the same as before. Booked absences, approved leave requests, and the days already taken were not touched at all, and overtime balances were carried over. Your employees see the same numbers after the change as they did before.
Preserving the remaining balance is a guarantee rather than a side effect. absentify recalculated each allowance year from the new rule and compared the result against the balance stored before the change. Where the two differed, it wrote a dated correction for exactly the difference, so the remaining balance reproduces the previous value. The conversion only added rules, rule assignments, and correction entries. It never wrote to leave requests or absences, and it stored a copy of the previous values before it started, so the original figures remain available.
Because the goal was to reproduce your previous balances, absentify did not apply any rule retroactively. If a balance was stored before a carry-over expiry deadline that has since passed, that balance is preserved as it stood rather than expired after the fact.

What your data looks like now

Open Settings > Users, select an employee, and open the Allowance tab. Compared with before, you will notice the following.
  • Each allowance type shows the rule that applies. The summary line names the Current rule with its Valid from date and either Valid until or No end date. Where an employee’s entitlement changed over the years, absentify created several consecutive assignments instead of one, so each period keeps the amount it actually had.
  • The year table names the rule per year. Each row is one allowance year, and the rule that applied is shown under the Year column. Hovering the allowance value breaks it down into the amount from the rule, manual adjustments, and any balance correction from the conversion.
  • Differences were preserved as dated corrections. Where the previous yearly numbers could not be expressed by a single rule, absentify recorded the difference as an adjustment. You will find these under History & adjustments with reasons such as Balance correction from migration (2026) or Prorated first year, created by Migration.
  • Allowance types point at an organisation default rule. In Settings > Allowances, the rule that new employees receive carries the Organisation default badge. absentify selected it automatically wherever one of your existing rules matched the allowance type’s previous standard amount. Where no rule matched exactly, or where the current and next year had different standard amounts, the previous default keeps working until you pick a rule yourself.
  • Departments point at a rule where possible. Under Allowance rules for new employees, a department’s previous standard quota now selects the matching rule. Here too, a default that did not match an existing rule exactly keeps showing the previous number fields until you pick a rule.
Corrections in the history are expected. They are the mechanism that kept your balances identical, not a sign that something went wrong.

What you should check

Ten minutes are enough for a meaningful review.
1

Spot-check two or three employees

Open Settings > Users > Edit > Allowance for a few people whose entitlement you know by heart, ideally one long-standing employee, one who joined partway through a year, and one part-time employee. Compare Remaining with what you expected.
2

Look at the rule assigned to them

Check the Current rule and its Valid from date. If the rule does not match the employee’s contract, assign a different one instead of correcting numbers by hand.
3

Open History & adjustments

Confirm that the corrections you see are labeled as coming from Migration. If a balance looks wrong, the correction entry tells you exactly which amount was preserved and for which year.
4

Check the rule for new employees per department

Open Settings > Departments and review Allowance rules for new employees. This is what the next person joining will get, so it is the setting most worth correcting now. Anything still showing the previous number fields has no rule selected yet.
5

Check hour-based allowances too

If you track overtime or any other allowance in hours, review those in the same way. They were converted with the same guarantee, but their amounts are easier to misread than day-based ones.
If an employee’s entitlement genuinely changes from a certain date, assign a new rule with that date rather than editing past years. Past calculations stay intact and the new rule applies from the date you choose. For assigning, ending, or removing rules after the conversion, including what Rule assigned means in the history, see Editing user allowances.

If you use the API or webhooks

This is a real behavior change, so read this section before your next integration run. Internally, the allowance value now stores only the part granted by the rule, while manual corrections live as separate adjustment entries. The public API hides that split so your integrations keep working:
  • The allowance field returned for a member is the effective allowance, meaning the amount granted by the rule plus all manual adjustments. It keeps the meaning it had before the change.
  • The internal adjustments field is not part of the payload.
  • PUT /members/{id}/allowance/{allowance_type_id}/{year} is deprecated, and in a converted workspace its allowance field is ignored. The request is accepted, but the value has no effect, so writing a value and reading it back returns the amount the rule grants, not what you sent. Before the conversion the calculation engine owned that value and overwrote it on the next recalculation, so a nightly sync that keeps sending it changes nothing, exactly as before. To change an entitlement, use POST /members/{member_id}/adjustments for a one-off correction or a rule for a recurring entitlement. brought_forward, compensatory_time_off, set_as_default, and disabled keep working. While a migration is running, or after a workspace was rolled back, the endpoint rejects the whole request with a conflict instead of applying part of it. If no rule assigns the member that allowance type for the requested year, or the year lies outside their employment period, it returns 404 Not Found. That is a permanent condition, so do not retry it.
  • Webhook payloads follow the same semantics. Where a payload carries a member’s allowances, the reported allowance is the effective value and adjustments is stripped, exactly as in the REST API.
New endpoints cover the rule model directly. They all require an admin API key and are grouped under Allowance Management: Amounts follow the allowance type’s unit: days for day-based types and minutes for hour-based types. See the API introduction for the full details. The Excel export also gained information. The Allowance sheet now shows Rule, Rule valid from, and Rule valid until, and splits the entitlement into Allowance (from rule), Adjustments, and Effective allowance. Two sheets were added: Adjustments, which lists every manual and migration correction with its reason, and Rules, which documents the rules configured in your workspace. Both are always present, even when they contain only a header row. See Excel and calendar exports.
If a report of yours reads the allowance column expecting the old fixed number, check it against Effective allowance rather than Allowance (from rule). Only the effective value matches what the employee sees and what the API reports.

What you gain

The conversion was not only housekeeping. A few things are now possible that were not before.
Instead of typing a number per person per year, you define the entitlement once as a rule and assign it. Changing the rule updates everyone assigned to it.
Assign a new rule with the date it takes effect. absentify prorates the change automatically and leaves past calculations untouched, so a promotion or a contract change no longer means manual recalculation.
Under Carry-over & expiry, decide whether Nothing, Everything, or an amount Up to a limit carries over, and for how long carried-over allowance stays usable. absentify applies it at the end of each allowance year.
Besides Yearly, a rule can grant the allowance Monthly or Bi-weekly. You can also choose whether each period’s amount is available Immediately or builds up Gradually.
Under How is a partial year counted?, pick In monthly twelfths, where whole months count 1/12 each and a started month counts by day, or Day-exact, where every calendar day counts. Some countries require the day-exact basis.

Getting help

If a balance does not look right after the conversion, do not correct it by hand before you have looked at History & adjustments. The entries there usually explain the difference. If anything is still unclear, contact our support team or write to support@absentify.com. Mention the employee and the allowance year you are looking at, so we can check the same figures you see.