Create, update and assign leave policies¶

A leave policy defines how a kind of time away works. An assignment makes that policy available to a person or to whoever holds a position during an effective period. Balance entries record the allowance actually available. These are separate parts of setup.

This guide follows the intended WorkOS Final Screens journey. The inspected frontend shows sample policies and forms. Create displays a success message without saving, Save returns to a sample list, and Assign has no connected submission. Confirm the connected environment before using these steps for real administration. Decisions, balance production and the remaining leave lifecycle are still being reconciled.

Before changing a policy¶

Use the correct organization and an account authorized to manage staff leave. The policy catalogue, full policy detail, creation, updates and assignments require leave-management permission. A visible HR tools label does not grant that permission.

Agree the policy owner, eligible people or positions, counting unit, review route and required evidence. Confirm business hours, holiday dates and any published workflow with their owners. Saving a policy does not test all of those dependencies; a later request can still be blocked by missing configuration.

Choose a new, unique code for a new policy. The current create operation updates an existing policy if its code already exists in the organization. Codes are normalized to uppercase. Do not use Create as a way to duplicate a policy under the same code. Open and review the existing policy first when changing its rules.

Saving changes replaces the policy's rule groups. Review all groups, including settings you intend to retain. Existing request records keep the policy facts copied when they were submitted; a policy update is not a command to rewrite requests, release reserved units or correct balances. Later processing can have its own dependencies on current policy rules.

Review the catalogue¶

1. Open Leave, then Policies.
2. Compare the name, family, accounting unit, approval mode and code.
3. Choose Open for the policy you intend to inspect.
4. Confirm the selected policy before changing any rule or assigning it.

The catalogue represents policy definitions, not a list of people entitled to each policy. Counts by approval mode describe the policies in the returned list. They do not count leave requests, reviewers or assignments. The current catalogue read returns the complete list; sample page controls do not establish server pagination.

Create a policy¶

1. From Policies, choose Create policy.
2. In Details and approval, enter the policy name, unique code, family and accounting unit. Choose the approval mode, notice and duration rules, supporting-file requirement, and the workflow binding when workflow approval is used.
3. Choose Next step. In Carryover, cover, and dates, set carryover, cover, date-counting, balance and accrual rules. Use the conditions below; some fields labelled optional become required for the selected rule.
4. Choose Next step. In After approval, choose whether withdrawal, revocation, call-back, suspension planning and resumption are allowed. Each action still depends on the request's state and the acting person's authority.
5. Use Back to review earlier groups. Confirm all settings, then choose Create policy.
6. In a connected implementation, verify the returned policy in Policies and reopen its detail. Check its identity, code and complete settings before making assignments.

The inspected backend has one policy-save operation. The three screens do not establish three persisted drafts or a separate publish/activate approval. The current frontend's success toast does not prove a policy was created.

Choose compatible settings¶

Workflow versions omitted or supplied as nonpositive through the inspected service are normalized to version 1. Set the intended version explicitly; a successful policy save is not proof that version 1 is the right process.

Resolve coverage by position is not independent of the selected cover method: the stored setting is derived from that method. Review the saved values together. Do not expect an unchecked box to override an explicitly position-based method.

Carryover, entitlement and accrual describe policy configuration. Verify actual balance meanings separately. Manual corrections have their own posting and recovery rules. The inspected source has no automatic allowance-posting job. Updates and reporting explains this implementation limit and rollout responsibility.

Update an existing policy¶

1. Open the policy from Policies and confirm the selected identity and code.
2. Review Policy details, Request rules, Approval route, Carryover rules, Coverage requirement, How dates are counted, Entitlement and accrual, and Actions after approval.
3. Change the intended settings while retaining the others. Remove the workflow binding if switching away from workflow approval; clear fixed units if switching to another accounting unit.
4. Choose Save policy. Reopen the saved detail and compare all groups with the intended result.
5. Review assignments and balance implications separately. Do not assume the update backfills grants, changes past requests or migrates balances between units.

An explicit update cannot take another policy's code. Discard returns to the catalogue in the intended flow; the current demonstration does not establish persisted drafts or undo after a real save. Coordinate concurrent administration because the inspected policy contract has no version token for detecting another person's intervening edit.

Assign a policy¶

1. Open the saved policy detail.
2. In Assign this policy, choose one Staff member or one Position. Leave the other target empty.
3. Set Effective from. Add Effective to only when the assignment should end; the connected HTTP validation requires an end later than the start.
4. Verify the target, policy and exact period, then choose Assign policy.
5. Confirm the assignment result and its effective dates. When it becomes effective, verify the intended person's policy choices and a correctly dated request. Future assignments may not appear in today's choices.

A position assignment follows position resolution at the relevant time. A direct staff assignment takes precedence when the same policy also applies through a position. Assignment does not grant product access, prove employment or position readiness, or immediately post allowance.

For the same policy and target, overlapping assignment periods are rejected. Assignment boundaries include the end instant: an earlier assignment ending exactly when the next starts overlaps under this check. An assignment with no end continues indefinitely. Do not confuse this with the exclusive-end calculation for a leave request itself.

The inspected policy API has no assignment amendment, removal or assignment-history read operation. The policy detail response also does not list assignments. An administrator cannot rely on reopening that detail alone to verify who has the policy. Record the returned reference through the supported operational process and escalate corrections; do not create overlapping replacements or assume a hidden delete action exists.

Recover from an unexpected result¶

Rollout owners should test a permitted administrator, an ordinary member, conflicting assignments and failed/uncertain saves in the connected environment. A completed form, sample success message or passing documentation check does not establish that readiness.