Skip to content

Just-in-time approvals

Just-in-time (JIT) approvals give users access only when they need it, and only for a limited time. An admin sets the approval policy on an entitlement. The policy controls who must approve a request and the maximum duration a user can request. When the duration ends, Trustle removes the access automatically. This replaces standing access, which is access with no expiration that persists until someone removes it.

Each entitlement has an approval policy. By default, the entitlement inherits the policy of its connection. An admin can customize the policy for one entitlement. A customized policy replaces the connection policy as a whole.

When a user submits a request, Trustle evaluates it in this order:

  1. If an admin approves with admin override, and the policy allows admin override, the request is approved. The requested duration must still be within the policy maximum.
  2. The requested duration must be within the maximum request duration. Trustle rejects a request that asks for more.
  3. The approval workflow decides who must approve. If the user has self-provisioning authorization for the entitlement, Trustle approves the request automatically.

Durations follow these rules:

  • Trustle accepts any duration from 1 minute to 730 days, within the policy maximum.
  • A week is 7 days, a month is 30 days, and a year is 365 days.
  • A request that nobody approves or denies within 7 days expires. The user can submit a new request.

When access expires, Trustle removes it from the connected system. For a role elevation, such as a higher role on a GitHub repository, Trustle reverts the user to the role they held before the elevation. It does not remove the user.

  • You must have the Trustle admin role. The Settings page and policy changes are available to admins only.
  • Connect the system that holds the entitlement. See the page for your system under Integrations.
  • Decide who approves requests for the entitlement: the requestor’s manager, a list of users, or both.

Step 1: Set the durations that users can pick

Section titled “Step 1: Set the durations that users can pick”
  1. In the sidebar, click Settings.
  2. Find the Access Request Durations card. These durations appear in the access request pickers.
  3. To add a duration, enter a number in Duration, select a Unit (Minutes, Hours, Days, or Weeks), and click Add. For example, enter 4 and select Hours.
  4. To remove a duration, click the remove icon next to it.
  5. Click Save Changes.

The default list is 1 hour, 1 day, 1 week, 1 month, 3 months, and 1 year. The list must hold at least 1 and at most 20 durations. Each duration must be between 1 minute and 730 days.

The list only controls what the pickers show. Trustle also accepts other durations within the limits above. A picker does not show a duration that is longer than the entitlement’s maximum.

  1. Open the entitlement from Connections.
  2. Click the Approval Policies tab. The Approval Policy card shows the policy that the entitlement inherits.
  3. Click Customize Policy. Trustle copies the connection policy to the entitlement so that you can edit it.

To go back to the connection policy later, click Reset to <connection> Defaults, then click Reset Policy.

In Maximum Request Duration, select the longest time that a user can request to keep this access: 1 Hour, 1 Day, 1 Week, 1 Month, 3 Months, or 1 Year.

A policy with no maximum shows Unlimited. For JIT access, select a short maximum, such as 1 Day.

In Approval Routing, select who needs to approve requests to access this entitlement:

Option Who approves
Manager The requestor’s manager.
Single Approval Any 1 of the Designated Approvers. The first approver to approve completes the request.
Quorum Approval At least the Quorum Size number of the Designated Approvers. The quorum size cannot be more than the number of approvers.
Two-Level Approval One approver from First-Level Approval, then one approver from Second-Level Approval.

For Two-Level Approval, set each level to Designated Approvers or Requestor’s Manager. Both levels cannot be Requestor’s Manager. The same user cannot be in both levels.

If a level uses Requestor’s Manager and the requestor has no manager, Trustle denies the request. If admin override is on, the request stays pending so that an admin can approve it.

Turn on Allow Admin Override to let Trustle admins approve or deny requests before the designated approvers. If the policy does not set this option, admin override is on.

  1. Turn on Escalate Unanswered Requests. When nobody acts on a request within the delay, Trustle adds the escalation approvers to the request and notifies them.
  2. In Escalate After, select a delay, such as 4 Hours.
  3. In Escalation Approvers, select one or more users.

The original approvers stay on the request. An escalation approver can approve the request alone, even when the policy requires two levels or a quorum. Trustle escalates a request one time only.

Click Save Changes.

To let a user request the same access again without new approval for a period, turn on Self-Provisioning. See Self-provisioning.

A requestor selects the entitlement, selects a duration from the picker, and submits the request. The picker shows only durations up to the entitlement’s maximum.

Approvers receive a notification in Slack, Teams, or email, based on the organization’s configuration. The email has a Review Request button that opens the request. An approver can approve or deny the request there, or from Manage Requests.

Before an approver decides, the approver can change the duration or the role of the request, or move the request to a different entitlement on the same connection. After one required approver approves, these changes are not available. A new duration must be within the policy maximum. The request history records each change.

A user can extend access before it expires. Trustle adds the new duration to the current end date. Each extension request must be within the maximum, but the total can be longer.

For a role elevation, the user sees the elevated role and the role they return to. For example, a user with the write role on a GitHub repository requests the admin role for 1 week. The grant message tells the user that the role is elevated to admin and reverts to write on expiry. A reminder before expiry says that the role will revert. After expiry, a message confirms that the role reverted and that the user still has that access. An elevation cannot last longer than the access the user held before it.