Admin: Application Settings

Admin: Application Settings Governance

Use Application Settings to define tenant-wide guardrails for new application requests, approval behavior, TOPdesk ticketing, metadata quality, ownership requirements, and secret/certificate governance in AZExecute.

Governance Objectives

• Improve request quality with consistent metadata requirements

• Cap newly configured secret and certificate lifetimes when a maximum is set

• Require ownership coverage to prevent unmanaged applications

• Standardize environment and department classification

• Control application request approval behavior and optional TOPdesk ticket creation

Setting Areas

• General: enable app creation, approval flow, user import, all-application visibility, owner deletion, and credential lifetime limits

• Registration Configuration: optionally give authorized application administrators a guided editor for redirect platforms, authentication behavior, app roles, identifier URIs, exposed scopes, and pre-authorized clients

• Metadata: choose which request/edit fields are visible and which included fields are required

• Application Requests: route requests through a validated TOPdesk integration and configure create/approve/reject incident behavior

• Environments and Departments: maintain tenant picklists used by application metadata

• Ownership: set minimum co-owner count, notification target, and default administrators for newly created or imported applications

Default administrators are applied to new application records. Changing the list does not retroactively rewrite administrator assignments on existing applications.

Enable Registration Configuration allows application administrators to write supported registration properties directly to Microsoft Entra. It does not allow them to grant API permissions or bypass consent governance. Review the complete behavior and rollout guidance before enabling it.

Application Request Availability and Approval

The General settings decide whether users can request new applications and whether an administrator must review each request before creation. These settings affect the user experience immediately, so they should be tested with a normal requester account before rollout.

• Enable App Creation: shows the application request experience to users and lets them submit new application registration requests

• Use Approval Flow: requires an administrator to approve, reject, import, or otherwise complete the request before the application is created or connected

• When approval flow is disabled, AZExecute can create the application registration and enterprise application service principal immediately after submission

• API permissions included in the request still become Permission Requests and follow normal internal or external approval, even when the application itself is created without approval

Application creation requires the tenant to have the required Entra ID setup and permissions. External API approvals may also require the approving administrator to have Global Administrator, Application Administrator, or Cloud Application Administrator access active before approval.

Ownership Defaults and Created Applications

Ownership settings help ensure that applications created or imported through request workflows do not become unmanaged. They combine requester-selected owners with tenant-wide administrator defaults.

• Minimum co-owner requirements control how many responsible people a requester must add before submission

• Default administrators are added to newly created or imported application records so platform teams retain a management path

• When a new request is fulfilled by creating an application, both the Entra app registration and enterprise application service principal are created

• Owner and administrator policy should be reviewed with the teams that maintain application lifecycle, credentials, and permission governance

Metadata Strategy

Start with a minimal required set, then expand mandatory fields as your governance maturity increases.

• Keep Business Justification required for all requests

• Require Environment and Department/Team for reporting and ownership routing

• Require Elevated Permissions Justification when elevated access is enabled

• Require Contact Email for operational follow-up and incident response

Review required-field impact with application owners before enforcing additional required metadata to avoid request friction.

Available Metadata Fields

• Core Context: Business Justification, Project Name, Department/Team, Environment, Business Criticality, Intended Audience, Expected Go-Live Date

• Requirements: Technical Requirements, Data Access Requirements

• Compliance & Contact: Compliance Notes, Requires Elevated Permissions, Elevated Permissions Justification, Contact Email, Contact Phone

TOPdesk for Application Requests

Application Settings can connect application request workflows to a validated TOPdesk integration. This allows a request to create a TOPdesk incident or change, display the ticket number and link on the request, and update or close the ticket when the request is approved or rejected.

What Administrators Configure

• The TOPdesk integration that should be used for application requests

• Whether the workflow creates an incident or a change

• Whether a ticket is created when the request is submitted

• Optional entry type, category, subcategory, operator group, and approval or rejection processing statuses

• Whether approval and rejection should update the ticket or close it

What Users and Reviewers See

• The request dialog shows when TOPdesk ticketing is enabled for the workflow

• After TOPdesk creates the ticket, the ticket number and link are shown on the request and approval dialog

• If ticket creation, update, or close fails, administrators should review tenant operations logs and the TOPdesk integration validation status

TOPdesk settings depend on provider-side values such as categories, operator groups, and processing statuses. Revalidate the integration and review application request settings after TOPdesk configuration changes.

Recommended Rollout

1. Configure settings in a maintenance window

2. Validate with test requests from a non-admin account

3. Test both approval-flow enabled and disabled paths if your organization plans to use both

4. Submit a request with internal and external API permissions to confirm the Permission Request handoff is clear

5. If TOPdesk is enabled, confirm ticket number, link, approval update, rejection update, and logging behavior

6. Announce changes to application owners and requesters

7. Revisit required metadata quarterly based on audit findings

Validation checklist: test a new application request, verify required-field validation, verify environment/department picklists, confirm ownership defaults, confirm API permission request creation, and confirm TOPdesk ticket behavior when enabled.