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 user 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 users, and a user 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 user 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 users 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 a user, 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 a user’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. The info icon next to 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. Under Settings > Users > Default User Settings, Allowance rules for new users shows the rule new users receive per allowance type. 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 Settings > Departments, in 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 users

Open Settings > Users > Edit > Allowance for a few users whose entitlement you know by heart, ideally one long-standing user, one who joined partway through a year, and one part-time user. 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 user’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 users per department

Open Settings > Departments and review Allowance rules for new employees. This is what the next user 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 a user’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 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 rule amount plus adjustments, excluding compensatory time off. Compensatory time off is reported separately as compensatory_time_off. It keeps the meaning it had before the change.
  • Member payloads omit the internal adjustments field. The dedicated GET /members/{member_id}/allowances endpoint includes a public adjustments field that excludes compensatory time off.
  • PUT /members/{id}/allowance/{allowance_type_id}/{year} is deprecated. In a converted workspace, allowance is an absolute target for that year. absentify stores the difference from the user’s rule entitlement as one Set via API adjustment and overwrites that entry on each send. Adjustments you created in absentify are never changed and still count on top. For a user with no rule yet, allowance is accepted and has no effect. brought_forward, compensatory_time_off, set_as_default, and disabled keep working. A field the integration omits keeps its stored value. Conflict and 404 responses are unchanged. See the API introduction for the full contract.
  • 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, as in REST API member payloads.
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. Assignment responses include coverage_start_date, the first day this member actually accrues. That can be later than rule_start_date when they joined after the assignment began. rule_start_date stays the assignment’s own start and is the value you send in a POST or PATCH. 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 user 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. For those cycles you choose whether the amount is credited At the start of each period or At the end of each period.
Yearly rules can count partial years by month, by day, by full months only, or grant the full amount on joining or leaving. Mid-year rule changes still count each rule for its own period. See Partial years for examples and the restriction on Always the full amount for pre-migration balances.

​
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 user and the allowance year you are looking at, so we can check the same figures you see.