Apps and Identity Requests

Identity solution

Build focused, secure forms that let the right people request, approve, or perform identity tasks without giving them broad Studio access.

At a glance

NIM Apps provide controlled, user-facing forms for delegated administration, identity requests, and specialized account tasks. An App collects the required input, validates it, and runs only the form actions you configure; access to the App is granted deliberately to the approved internal users and groups.

Before publishing: Test the App in Run mode with safe data, verify each action produces the intended change, and confirm that only the expected users and groups can access it.

Start with an App pattern

1

Explore proven App patterns
Review examples for delegated password reset, emergency termination, user management, and controlled exceptions.

2

Build an App end to end
Design forms, collect input, add actions, test safely, and publish a controlled experience.

3

Make it easy to use
Customize the App dashboard so approved users can find the experiences assigned to them.

Use form actions to define what the App can change, and manage access deliberately before publishing.

Choose the right request pattern

Need	Use	Control to verify
A repeatable task needs input from an approved operator or end user	A NIM App with focused form items and actions	The form collects only the needed input and exposes only the intended action.
A user needs to reset a password or activate a prepared account	Self-service identity	The user completes the required verification before the action runs.
Trusted source data already determines the required change	A filter, mapping or role, job, and sync task	The automation qualifies the correct population without waiting for a manual request.
A normal access rule needs an approved exception	Role Group Overrides App	The exception is controlled without changing the general eligibility rule.

Test a request App end to end

1. Define the user, requested outcome, required input, and target-system action before building the form.
2. Use Run mode with safe data to confirm validation, variables, conditional behavior, and every form action.
3. Verify the completed target-system change and its corresponding audit information.
4. Confirm that an approved user can access the App and that an unapproved user cannot.
5. Publish only after the form’s input, actions, and access group match the intended task.

For write actions, use disposable records during testing. For an App action that fails after valid form input, review the related target operation and follow Troubleshoot NIM provisioning failures.