Skip to main content

How petitions work

Petitions provide your team with a unified interface to manage changes to custom resources, whether they're in external systems (e.g. identity providers, cloud apps) and internal systems (e.g. databases, home-grown tools). Think of petitions as similar to pull requests except instead of code, it's access that's being reviewed.

Requesting access for yourself, granting someone else access, revoking a contractor's access... They're all petitions!

define: petition (noun) A petition is a formal written request, typically one signed by many people, appealing to authority with respect to a particular cause.

Petition phases

Petitions move through different phases from the time they’re created to when they’re reviewed and closed. This enables teams to bring their existing change management process, controls and systems, while seamlessly automating rote tasks like end-users updating a service desk ticket's fields or IT bugging a reviewer since they might've missed a number of requests from last week.

Petitions can take on the following phases:

StatusDescriptionPossible Actions
draftStarting point for all petitions-anyone can still edit the petition at this point. By default, creating petitions opens them for review.Open for review, or delete.
openThe petition has been finalized, and is awaiting action from the reviewers—petitioners can no longer edit it.If requirements are met, granted. If not, denied. Reviewers can edit it.
grantedThe petition was granted, and may be revoked in the future.Reviewers can revoke, or if time-bound, automatically revokes.
revokedThe petition expired or was revoked, and applied changes.Automatically moved to closed.
closedThe petition was denied, cancelled, revoked or has no more steps.Create another petition from this one.
deletedThe draft was no longer necessary.Petitioners can edit, retry, or close.

Steps of the petition

Step 1: Drafting the petition

Users can quickly find access they need and how to submit a request from the Indent web dashboard or Slack app. They can search for relevant resources based on their role or current task.

Related: Making your first request

Step 2: Messaging reviewers

Once users have selected the access they need, pre-qualified requests are routed automatically to the right reviewers; instead of having IT shepherd every request. Here's what that process looks like:

sequenceDiagram autonumber User->>Indent: Request access Note left of Indent: Group / Super Admin / INCIDENT-123 Indent->>Manager: Message for review Manager->>Indent: Approved for 30 min Indent->>System Owner: Message for review System Owner->>Indent: Approved for 15 min Note right of Indent: Integration triggered Indent-->>User: Granted for 15 min Note left of Indent: 10 min later Indent-->>User: Access will expire in 5 min Note left of Indent: 5 min later Note right of Indent: Integration triggered Indent-->>User: Access revoked

Step 3: Granting and revoking access

After all the requirements have been met, Indent will attempt to make the changes necessary to grant access.

First, it tries find a configured integration to use for interacting with the remote system, then Indent will use the integration to apply the necessary changes. If it's successful, the user will be notified. Indent will re-try with an exponential backoff until it's no longer likely to succeed.

If access was granted for a period of time, Indent will wait until either that duration expires or a reviewer revokes access to apply the changes to deprovision access. These steps may take different forms based on the who and what’s being requested.

sequenceDiagram autonumber Indent->>Integration: Granted for 30 min Integration->>Remote System: Make ACL changes Remote System->>Indent: 200 Response Note left of Integration: 30 min later Indent->>Integration: Revoked Integration->>Remote System: Make ACL changes Remote System->>Indent: 200 Response