Resource configuration reference
Configure resources in Admin > Access > Resources. You need Modify resources permission; changing a resource's review policy also requires Manage review policies. Available tabs and controls depend on the resource type and fulfillment method.
For the relationship between a resource, an assigned resource, and Grants, see The Owlie model.
Basic info
| Setting | Default or blank value | Effect |
|---|---|---|
| Name | Required; 3–100 characters | The name shown to administrators and people requesting access. |
| Picture | Blank | An HTTPS image URL, image data URI, or @domain brand hint. |
| Description | Blank; up to 1,000 characters | Explains what access provides. |
| Tags | None | Comma-separated labels used to categorize the resource. |
| Risk level | 3 for a newly created resource | A value from 1 (minimal) to 5 (critical), used when access decisions resolve risk. |
| Enabled | Enabled for a newly created resource | When disabled, the resource cannot be requested or newly assigned. Existing assigned access is not removed. |
| Allow multiple | Off | Lets one identity hold more than one instance of the resource. Changing this does not merge or remove existing instances. |
| Owner | No owner | Select a user or group. The owner can be resolved by App Owner approval steps and used by owner-based governance. |
Resource type determines the remaining controls:
- Assignable item creates an access assignment and can use access duration, self-extension, approval sequencing, and emergency access.
- Task completes request work without creating an ongoing Assigned resource. Owlie still records the request and its fulfillment execution. Its fulfillment choices are limited to a specific user, group members, or a function.
- Bundle groups 1–50 assignable items. Each component can include pinned Grants. Duration and approval settings belong to the bundle request; fulfillment is performed by its components.
Capacity is optional. A blank value means no configured capacity limit.
Approval
Approval stages run from top to bottom. Every stage must pass before the next starts. Each stage contains one or more approvers and uses one of these rules:
| Stage rule | Result |
|---|---|
| All approvers | Every approver must approve. By default, the first rejection fails the stage; Continue after rejection waits for all decisions. |
| Any approver | One approval passes the stage. |
| At least N of M | The configured threshold must approve. |
Approver types are Auto Approve, Manager, App Owner, User, Group, and Function. User, Group, and Function require a selected target. Manager and App Owner are resolved from the request context and resource owner. A new stage defaults to All approvers, Auto Approve, and fail on the first rejection. Copy replaces the current stages and approval sequencing with another resource's supported flow.
Timing override
Timing is inherited from the tenant unless Override is enabled. Approval and Fulfillment have the same controls, and each phase's clock starts when that phase becomes active.
| Control | Unit and default | Meaning |
|---|---|---|
| Due after | Days; blank inherits | Makes the phase due 1–365 days after activation. |
| Due-soon reminders | Comma-separated days before due; blank inherits | Sends reminders at the listed offsets. Override with none suppresses inherited due-soon reminders. |
| Overdue cadence | Days; blank inherits | Sets the interval between overdue reminders. |
| Overdue reminder cap | Count; blank inherits | Limits overdue reminders; 0 disables them. |
| Escalation | Inherit tenant setting | Choose inheritance, no escalation, or escalation. Escalation requires Escalate after overdue in days and an action. |
| Escalation action | Conditional | Approval can reassign to a user or group, reassign up the manager chain, run an approval function, or alert admins. Fulfillment can notify the resource owner, notify a user or group, or alert admins. |
| Expiry | Inherit tenant setting | Choose inheritance, never expire automatically, or Expire after overdue in days. Expiry must be later than escalation when both are set. |
| Overall ceiling | Inherit tenant setting | Choose inheritance, no overall ceiling, or close after a maximum number of days counted from when the request opens. |
Blank values inside an enabled override continue to inherit. Clearing Override returns every timing field to tenant inheritance. Timing is captured for request processing; do not use an edit as a way to retime work already underway.
Screenshot placeholder: Request timing. Annotate the timing control and its timer preview: phase start, due time, reminders, escalation, expiry, and overall ceiling. Distinguish inherited values from resource overrides. Essential meanings remain in the table above.
Access duration and sequencing
These settings appear for assignable items and bundles, not Tasks.
| Setting | Default or blank value | Effect |
|---|---|---|
| Permanent access | Allowed | Forbidden requires a default duration or maximum duration. |
| Default duration | Blank | Used when no end is requested. |
| Maximum duration | Blank | Caps request-backed and directly granted access. A default cannot exceed it. |
| Requester may choose a shorter duration | Off | Lets the requester choose a duration below the maximum. |
| Requester may schedule a future start | Off | Lets the requester select a future start; otherwise duration begins when provisioning starts. |
For assignable items, Self-extension is off by default. When enabled, Lead time defaults to 30 minutes. Blank Extension length reuses the original access-window length, and blank Maximum extensions allows unlimited extensions.
When access begins defaults to Approve before access begins. Grant trusted repeat access before ratification is the provisional-access option: it is available only when the person's prior access was approved. It requires a positive ratification deadline; failure cooldown is optional. Rejection or expiry revokes provisional access, and the cooldown delays another provisional grant.
Emergency access
Emergency access is off by default and is available only for assignable items. It grants short-lived access before approval, then runs the ordinary approval flow as ratification. Deny policies still apply.
When enabled, configure:
- Maximum duration (default 60 minutes) and Ratification deadline (default 30 minutes). The deadline cannot exceed the maximum duration.
- Optional Failure cooldown, in hours, after rejection or timeout.
- Who may invoke it and Who may receive it, using people, groups, or identity filters. At least one include rule is required for each; exclusions win.
- One or more invocation relationships: For themselves, As the beneficiary's manager, or For any selected beneficiary.
- Create post-event owner certification, on by default. This creates a certification item for the resource owner after access is granted.
The setting is evaluated when emergency access is requested. Disabling it prevents new emergency requests.
Fulfillment
| Fulfillment type | Available for | Behavior |
|---|---|---|
| Virtual | Assignable items | Owlie completes an approved request without handing work to another actor. |
| Specific user | Assignable items and Tasks | The selected user owns fulfillment work. |
| Group members | Assignable items and Tasks | Members of the selected group can fulfill the work. |
| Function | Assignable items and Tasks | The selected fulfillment function handles the work. |
| Connector integration | Assignable items | The selected installed integration performs provisioning operations. You cannot select an integration that is being deleted. |
Owlie selects the fulfillment method when it prepares request fulfillment. Changing this setting does not reassign an existing fulfillment ticket.
Form
The Form tab defines the fields requesters complete. An empty form collects no additional answers. Saving replaces the resource's form definition; existing requests keep their submitted data. Before removing a field, update any provisioning mappings that reference it.
Provisioning
The Provisioning tab controls how the connector changes access. It contains Provision, Revoke, Enable, Disable, Update Attributes, Add Grants, Remove Grants, and Set Grants operations. See The Provisioning and Grants tabs for mappings, hooks, and identity references.
- Provision defines the account creation mode, baseline attribute mappings, baseline Grants, and before/after hooks.
- Revoke defaults to removing managed Grants and setting the account state to Disabled. It can instead delete the account, and can run hooks.
- The remaining operations configure hooks around their corresponding connector action.
The saved profile is used to compile provisioning operations. Use the preview in Provision to inspect resolved baseline data before saving.
Screenshot placeholder: Connector provisioning. Show the Provision operation with its account mode, baseline mappings, Grants, and preview. Label which controls depend on the connector; do not imply the same controls exist for manual fulfillment.
Grants
Grant kinds declare the categories of entitlement the resource offers. Each kind's values are the targets currently known to Owlie for that resource.
For non-connector fulfillment, you define kinds and values. Save a newly added kind before editing its values. The editor loads every stored value before enabling edits because saving replaces the stored list for that kind. For connector fulfillment, kinds come from the connector configuration and values are read-only, but you can still change each value's Requestable state, risk rating, and access-review policy override.
Only values marked Requestable are offered for direct requests; a retired value or a value blocked by its current configuration is not requestable. Baseline Grants under Provisioning are added whenever the Provision operation runs. Depending on the integration's provision mode, that operation may create an account or attach to an existing matching account.
Review policy
By default, a resource inherits the tenant access-review policy. Override policy starts from the effective inherited policy and stores only resource-specific differences. Individual fields left unchanged continue to inherit. Clear override removes those differences on save and returns the resource to tenant inheritance.
The policy controls review stages and whether reviewers must give reasons to keep or revoke access. Test policy previews the effective tenant-and-resource result for a selected identity. A Grant value can carry its own review-policy override from the Grants tab; that more specific policy applies to that Grant while other values continue to use the resource policy.