A contractor needs access to a project area for two weeks. The manager approves the request, but that leaves two questions unanswered: what did IT actually grant, and who will confirm its removal?
A temporary access request form should connect the business reason, the permission being approved, the implementation evidence and the end date. Folderit can hold that record, route an approval, ask IT to complete assigned fields and send date-based reminders. The account or permission change still happens in the system that controls access.
This example is an illustrative configuration based on Folderit’s documentation, not a combined workflow tested in a live account. eForms and Workflow Designer are available on Tailor. Adapt the roles and review requirements to your organisation’s access policy.
Keep one person, one resource and one access period together
Use one record for a clearly defined access decision. If a contractor needs a project folder, a finance application and an administrative role, those may have different owners and removal arrangements. Separate requests make it easier to see which permission has been approved and which action is still outstanding.
Describe the resource precisely. “Project Orion / Released drawings / read only” is more useful than “same access as the project team”. The latter leaves IT to discover which of another person’s permissions were intended.
Create a Temporary access request template under Admin tools → Form templates. Folderit’s eForms guide explains the field types and how to create a record from the Upload dropdown in a folder. A useful starting form is:
| Field and type | What to enter |
|---|---|
| Request reference — Text | Your agreed reference, such as TAR-026. Enter it manually unless you separately configure numbering. |
| Person and account reference — Text | The person who needs access and an unambiguous account identifier. A requester may be submitting on their behalf. |
| Resource — Text | The system, project, folder or other resource, including the relevant location or identifier. |
| Requested permission — Text | The exact role or allowed actions, including exclusions that matter. |
| Business reason — Textarea | The task requiring access and why that permission is needed. |
| Requested start date and End date — two Date fields | The proposed access period. The reviewer checks that the end follows the start. |
| Timing details — Text | An exact cut-off time and time zone when the date alone is insufficient. |
| Business sponsor and IT owner — two User fields | The internal sponsor responsible for the need and the person responsible for implementation and removal. |
Require the information needed to decide the request. A User field selects a Folderit user, so use an internal sponsor for an external contractor rather than assuming the contractor has an account. Do not collect passwords, recovery codes or API keys in the form.
Add a separate implementation section for Fulfilment state (Select), Permission actually granted (Text), Granted date (Date), Implementation evidence (Textarea), Removed date (Date) and Removal evidence (Textarea). Use states such as Not started, Active, Not granted, Removed and Removal issue. The coordinator initially selects Not started.
Leave those later completion fields optional when the request is created. A requester cannot truthfully supply a future grant or removal date. Fulfilment state is a manually maintained operational value; keep the approval decision in the workflow rather than adding a competing “Approved” checkbox.
Approve a specific scope before asking IT to act
Give the business sponsor and resource owner distinct jobs if your policy requires both. The sponsor confirms the business need; the resource owner checks whether the specified access is appropriate. Choose the actual recipients when setting up the approval workflow. Names in form fields do not automatically establish the recipient list.
A clear resolution is: “Approve access for the named person to the specified resource, with the requested permission, dates and timing restrictions.” Show the request fields to the reviewer. If the scope is too broad, request clarification and have the record corrected before a decision. Avoid approving one permission in a comment while leaving a different permission in the form.
For a straightforward process, open the record’s Workflow menu and build a custom workflow in Serial order: the required approval tasks first, then an IT Fill fields task. Configure completion and rejection rules to match your policy. The sequence is useful only if unsuccessful approval does not release the implementation task; include that case in testing.
A green approval indicator establishes the recorded decision. It does not establish that an account exists, that a role was assigned or that access has ended. Keep that distinction visible to the people covering the queue.
Have IT record the actual permission and its evidence
Use the Fill fields recipient settings to give IT the information needed to carry out the approved change and report the result:
- Under Visible field filter → Only include selected fields, include the person, resource, requested permission, dates, timing details and the implementation fields.
- Under Editable fields, select Fulfilment state, Permission actually granted, Granted date and Implementation evidence. Include those fields in the visible selection too.
- Leave the approved request scope visible for reference but outside the task’s editable selection.
- Add a note requiring IT to perform the change in the target system, verify it there, then record the role or permission granted and a suitable ticket or evidence reference.
The recipient completes the task with Fill fields, which updates the existing form record. An informational Due by date is not an automatic timeout or a mechanism that changes access. Choose recipients and deadlines explicitly.
If the available technical role grants more access than was approved, IT should record the mismatch and return it for a new decision. Completing the form is not a reason to grant the broader role. If access was not granted, record Not granted and the reason rather than inventing a completion date.
Control the record itself with Folderit’s folder and item permissions. The task’s field settings govern that recipient experience; they do not replace the account’s wider access settings. A Business sponsor or IT owner field does not grant permission to view the record. Restrict ordinary editing of approved request details and send changed scope or dates through a fresh approval process.
Plan removal as work that needs its own confirmation
Give the IT owner a removal procedure in the target system, with a responsible backup. Where that system supports automatic expiry, configure and verify it there. A Date field in Folderit does not create an expiry rule in another application.
For a reminder, open the form template’s Actions gear menu, choose Manage reminders and add a rule based on End date. For example:
- Timing: two days before End date.
- Conditions: Fulfilment state equals Active and Removed date is empty, using All conditions (AND).
- Recipients: a named IT user or a responsible IT group.
- Message: identify the request, resource and removal deadline using the exact field placeholders offered by the editor.
The automated form reminder guide explains these controls. Conditions are checked when the reminder starts and again when it is due. The email is a prompt for action, not evidence that removal happened. Review any exact time and time zone separately from this date-based nudge.
After checking removal in the target system, the coordinator can start a new Fill fields task for the IT owner to complete Removed date, Removal evidence and Fulfilment state. Set Removed only when the action is confirmed. If removal fails, record Removal issue and the next owner and action in the evidence notes, then follow your escalation process.
Do not silently extend the approved end date to clear an overdue entry. Record an extension as a new request or through your approved change procedure, preserving the earlier decision and the reason for the change.
Make the register distinguish approved, active and removed
Use Columns settings to show Person and account reference, Resource, End date, IT owner, Fulfilment state and Removed date. Use the form’s fields in Metadata search filters to investigate records whose end date has passed and whose state is Active or Removal issue. A general Date filter is not necessarily your form’s End date.
Compare the register with the target system. An empty removal field may mean the permission remains active, or it may mean IT forgot to record a completed removal. Both need investigation; neither should be resolved by guessing from the approval indicator. Folderit’s item-level workflow history records participants, decisions, comments and timestamps, and its workflow summary can support a review of the decision trail.
Fictional example: TAR-026 requests read-only access to Project Orion’s released drawings from 2 to 13 November. The owner approves that scope. IT records the exact group used, the grant date and ticket CHG-481, then selects Active.
The end-date reminder prompts IT to check the removal arrangement. Once the target system confirms removal, IT records the date and evidence and selects Removed. If the available group also permits editing, the original read-only approval is insufficient: the request needs a different implementation or a new decision.
This separation reflects a useful distinction in NIST’s Cybersecurity Framework 2.0, PR.AA-05: access permissions should be defined, managed, enforced and reviewed, with least privilege and separation of duties in mind. A request record supports the decision and review trail. Enforcement remains the responsibility of the systems controlling access; this example is not a claim of framework compliance.
Before rollout, try an approved request, a rejection, an incomplete request, a technical-role mismatch and a failed removal. Check that IT cannot change the approved scope through its task, a rejected request does not proceed, reminders reach the intended people and the register exposes unresolved work. Also test with an ordinary user’s permissions. Those checks establish whether your configuration works for the people who will use it.
