Admins can customize access request forms to control what information users provide when requesting access.

The default form acts as the baseline for all applications. For managed applications, admins can create application-specific forms to tailor the request experience.

Use this feature to:

• collect additional context for critical applications
• reduce unnecessary fields for simple applications
• improve approval speed and clarity

Navigation

1. Go to Settings
2. Select Access Request Form

User will see:

• Default Form
• Application Specific Form

Default form

The default form applies to all applications unless an app has its own custom form.

Configure the default form

1. Select Edit under Default Form
2. Use the form builder to:
   • show or hide fields
   • reorder fields
   • mark fields as required or optional
   • configure field details (description, placeholder, helper text)
3. Select Save changes

Application-specific form

Application-specific forms override the default form for individual applications.

Application-specific forms are available for managed applications.

The list shows each application and whether it uses the default form or a custom form:

• Default Form – uses the default configuration
• Custom Form – includes application-specific changes

Open an application form

1. Go to Application Specific Form
2. Select Manage
3. Search for an application
4. Select Edit

Customize the application form

Add custom fields

1. Select Add Custom Field
2. Choose a field type:
   • Text
   • Dropdown
   • Boolean
   • Date
3. Configure the field:
   • name
   • description
   • placeholder
   • required setting
4. Save changes

Field limitations

• Dropdown options must be under 70 characters. Options exceeding this limit can cause the request form to fail to load in Slack.
• The web form is not affected by this limit.
• Some fields may not appear in the Slack request modal due to Slack UI constraints.

Set a field's data source

Fields that offer a list of options can take those options from two places: a fixed list you type in yourself, or Zluri's own data for that application.

The Application Role field is the common case. Pointing it at Zluri data means requesters pick from the application's actual roles instead of typing a value or choosing from a list you maintain by hand.

Configure the data source

1. Select the field in the form builder.
2. In the right panel, open Properties.
3. Set Type to Single Select.
4. Set Data Source to Zluri Data.
5. Set Entity Type to Application Roles.
6. Select Save changes

Requesters now see a dropdown of the application's roles, and the request records the actual role rather than free text.

Why this matters

Approver insights evaluate the entitlement attached to a request. Where the role is collected as free text or from a fixed list, there is no entitlement to evaluate, so approvers see no SoD violations and no privileged-access flag on that request.

Use Zluri data only for applications where Zluri has already ingested role data. Where it has not, the dropdown appears empty to requesters.

Hide fields

Turn off fields that are not required for the application.

Reorder fields

Drag fields to change the order.

The Application field always remains at the top.

Save changes

Select Save changes.

Changes apply only to the selected application.

Form behavior

Default form updates

The system handles default form updates based on the type of change.

Change the form structure

• Add a new field
• Reorder fields
• Mark a field as required or optional

These changes apply only to applications that are still using the default form as is.

Changes to a field

• Rename a field
• Edit field configuration
• Delete a field

These changes apply to all forms where the field has not been modified.

Changes always flow from the default form to applications.

Changes made in an application-specific form do not affect the default form or other applications.

Note: Changes made to the default form do not apply to applications that already use custom forms. Update those forms individually if needed.

Field detachment

While editing a default field inside an application-specific form, the system creates a separate version of that field for that application.

After this change:

• the field becomes specific to that application
• changes made to the same field in the default form do not apply to this application

Example:

If the “Application Role” field is modified for one application, that version is no longer linked to the default form. Future updates to “Application Role” in the default form will not affect this application.