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.
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:
|Starting 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.|
|The 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.|
|The petition was granted, and may be revoked in the future.||Reviewers can revoke, or if time-bound, automatically revokes.|
|The petition expired or was revoked, and applied changes.||Automatically moved to closed.|
|The petition was denied, cancelled, revoked or has no more steps.||Create another petition from this one.|
|The draft was no longer necessary.||Petitioners can edit, retry, or close.|
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
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:
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.