A temporary departure from a company rule needs a clear boundary: which requirement is affected, who accepts the proposed arrangement, when it ends and what evidence will close it. An email saying “fine for now” rarely answers all four questions.
A policy exception request form keeps that information together. In Folderit, an eForm can hold the request, a field-completion task can collect the policy owner’s assessment, an approval workflow can record the decision, and date-based reminders can bring an active exception back for review. The organisation still decides whether the exception is permissible and carries out the agreed safeguards.
The configuration below is a hypothetical working example based on current Folderit documentation, rather than a combined workflow tested in a live account. Tailor includes eForms and the Workflow Designer; check your account’s features before setting up the process.
Define one exception with a specific end point
Use one record for one policy requirement, a defined scope and a proposed period. Name the policy and its version or effective date, then identify the relevant section. “Allow a different intake procedure for the North office’s delivery notes until 30 November” is more useful than “temporary operational exemption”.
Keep the underlying policy in its normal controlled library. Use the exception record to explain the limited departure and add a related-item link to the policy document where appropriate. The record does not change the policy for everyone else. Folderit’s policy management overview explains the separate work of drafting, approving and distributing the policy itself.
Before designing the workflow, establish who has authority to grant this type of exception. An internal approval cannot waive a law, a contractual obligation or a requirement outside that person’s authority. Refer those questions to the responsible specialist before seeking a decision.
Build a request section and a later assessment section
Create a Policy exception request template under Admin tools → Form templates. The eForms guide describes the supported field types and record creation. Start with these fields:
| Field and type | What belongs in it |
|---|---|
| Reference — Text | An agreed reference such as EX-026. Enter it manually unless numbering is separately configured. |
| Policy reference — Text | Title, version or effective date, and the section requiring an exception. |
| Requested departure and scope — Textarea | What would change, the people or locations covered, and explicit exclusions. |
| Reason and alternatives — Textarea | The business need and why a compliant alternative is not currently practical. |
| Requested start and end — two Date fields | A proposed period. The reviewer checks the date order and any precise cut-off time. |
| Record owner — User | The internal person responsible for follow-up, rather than an automatically selected approver. |
| Risks and safeguards — Textarea | What could go wrong and the proposed control, responsible person, frequency and evidence. |
| Supporting material — File, optional | Relevant evidence that the reviewers need to assess this request. |
Require the request information needed for assessment. Add optional later fields for Authorised scope and conditions (Textarea), Agreed start, Agreed end and Review date (Date), plus Closure evidence (Textarea). Keep them optional at creation: the requester cannot supply a future decision or completed closure evidence.
Add a manually maintained Record state Select field, for example Awaiting assessment, Awaiting decision, In force, Declined and Closed. This helps the coordinator manage follow-up. The approval decision remains in the workflow record; selecting In force is a separate human action after the decision and any prerequisites have been checked.
Collect an assessment before the approval
Ask the policy owner to review the scope, alternatives and proposed safeguards. For an information-security example, Yale’s published exception process separates the security team’s risk assessment from leadership’s acceptance of remaining risk. That is one organisation’s approach, not a universal approval rule; define the corresponding responsibilities for your own policy.
A Fill fields task can let the policy owner complete the assessment on the existing form record. Configure the recipient’s visible fields to include the original request and the assessment fields. Select only the assessment fields under Editable fields, and ensure they are visible too. Task-level field settings do not replace the record’s underlying sharing permissions.
Then send the completed record to the person authorised to decide it. A serial custom workflow can place field completion before approval; use the documented approval settings to define recipients and acceptance rules. Choose the actual recipients during setup. A name in the Record owner User field does not automatically route an approval to that person.
Make the resolution precise: “Approve the authorised scope, conditions and agreed dates recorded in this request.” If information is missing, obtain clarification before a final decision. Configure and test unsuccessful paths so a refusal or incomplete assessment cannot be treated as permission to proceed. If the agreed scope or dates later change, obtain a new decision rather than relying on the earlier approval.
Make safeguards observable: an intake-delay example
Hypothetical example: an office scanner is out of service. The internal procedure requires delivery notes to reach the central intake queue on the same working day. Operations requests permission to use a controlled paper log for five working days while a replacement arrives.
The request identifies one office and one document type. It excludes invoices and any documents subject to an external deadline. The proposed safeguard assigns the office coordinator to number each entry, secure the originals and reconcile the paper log with the intake queue every afternoon. The policy owner checks whether that arrangement is acceptable and records any stricter conditions before approval.
A useful closure record would identify the final log entry, the reconciliation date, any missing documents and who checked the result. “Scanner repaired” alone does not establish that the delayed records reached the queue. If a document is missing, leave the follow-up open and assign the recovery action.
Configure review reminders and decide what expiry means
Use Manage reminders on the form template to create a rule based on Review date, for example seven days before it. Add the condition Record state equals In force. Configure the responsible user or group, or use an eligible recipient field when the template offers it. The form reminder guide explains offsets, conditions and recipient options.
Conditions are checked when the reminder starts and again when it is due. Include the request reference, agreed end date and expected action in the message using the exact placeholders offered by the editor. Review the recipient configuration when responsibility changes.
A reminder is an email prompt. It does not end the exception, change Record state, disable an external process or certify that safeguards were performed. The owner must check the agreed end date and either record closure or seek a fresh, authorised extension. Test changed dates and existing records in your account; do not assume an already-passed reminder date will produce a catch-up message.
Check the exception register before rolling it out
Keep the register in a folder shared with the people who need it. Limit editing to the appropriate owners and coordinators. Where form fields are linked to metadata, display useful fields such as policy reference, owner, record state and agreed end as folder columns. Field labels and status values organise the work; configure access and workflow actions separately.
- Complete request: the policy owner can see the request and edit only the assigned assessment fields.
- Refused request: the coordinator records Declined and no operational exception is introduced.
- Approved with conditions: the owner confirms the required safeguards before marking the record In force.
- Changed scope or end date: the revised terms receive a fresh decision and the reminder configuration is checked.
- Closure or extension: closure evidence identifies the work completed; an extension retains a reference to the earlier request and has its own decision.
Run these cases with a small group before making the template available more widely. The useful outcome is a record another colleague can act on: the precise exception, the recorded decision, the safeguards still owed and the person responsible for closing it.
