Application Requests

This page explains how to submit complete Application Requests in AZExecute so approvals and delivery move faster. It focuses on what requestors should enter, what approvers look for, what happens after a decision, and how related permission and ticketing workflows are handled.

Some options and requirements are managed centrally by your organization. If a field appears required, hidden, or read-only, that is expected tenant policy behavior.

How To Use This During a Request

When you submit a new Application Request, these areas affect outcome and approval speed: General, Metadata, Request Context, Ownership, and optional API Permissions. Use them as a checklist to submit a complete, review-ready request.

General affects request availability and credential lifetime limits

Metadata captures business, security, and support context

Request context defines the environment and team ownership you select

Ownership requires maintainers so applications do not become unmanaged

API Permissions capture access needs that should be reviewed together with the new application

General: What Users Should Expect

General controls affect whether users can request new applications, whether an administrator must approve each request before creation, and which secret or certificate lifetimes users can choose.

• If application request creation is disabled, contact your platform team for the approved onboarding path

• If approval flow is enabled, the request waits for an administrator to approve, reject, import, or otherwise complete it

• If approval flow is disabled, the application can be created immediately, while requested API permissions still follow the Permission Request workflow

• Secret lifetime choices are capped by tenant policy

• Certificate lifetime choices are capped by tenant policy

Impact: If requested lifetimes are longer than policy allows, you must select lower values. This is expected and helps enforce credential hygiene.

Request Lifecycle and Outcomes

Application Requests keep their history visible so requesters and administrators can understand what happened after submission. The request list shows the current state, any administrator feedback, and a read-only details view after the request is no longer editable.

• Requested: the request is waiting for processing and can still be edited or deleted by the requester

• Accepted: the request was approved and fulfilled by creating or connecting the application

• Imported: an existing Entra application was matched and brought under management instead of creating a duplicate

• Denied: an administrator rejected the request; when a reason is provided, the request list shows a comment icon that opens the administrator message

• Deleted: the request was removed before completion and remains visible as a historical state where applicable

After a request is accepted, denied, imported, or deleted, use Details to open the submitted request in read-only mode. This lets requesters review metadata, ownership, requested APIs, and the administrator decision without changing the original request.

What Creation Produces

When AZExecute creates a new application from an accepted or auto-created request, it creates the Entra app registration and the matching enterprise application service principal. This gives the application both an app registration identity and a service principal that can be managed, owned, and used for access assignments.

• The requester and selected co-owners become part of the ownership model for the new application

• Tenant default administrators can be applied automatically according to Application Settings

• Requested metadata is saved with the managed application record for reporting, ownership review, and operational follow-up

• Requested API permissions become Permission Requests so access approval stays consistent with the normal permission governance process

The goal is to avoid orphaned application registrations. A completed request should leave the application with responsible owners, tenant policy administrators, and a visible request history.

Metadata: How To Fill It Well

Metadata provides the context approvers and operators need to validate risk, route ownership, and support your workload. Complete, precise metadata is the fastest way to reduce request delays.

If your tenant needs policy changes (for example additional fields or approval behavior), ask your administrators to review Administration settings.

Always Required: Business Justification is always included and required for every application request.

Business Context

• 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

If a field is marked required, you must provide it before submission. Missing or vague metadata is one of the most common reasons requests are delayed.

Request Context: Choosing Correctly

Environment and Department/Team selections are used for governance, routing, and reporting. Choose values that match real ownership and deployment intent.

Environments

Pick the environment that reflects actual runtime usage (for example Development, Test, Production).

Departments

Pick the team that will own operations and incident response for this application.

Hidden meaning: These values are often used in dashboards, ownership reports, and triage filters. Inconsistent choices reduce operational visibility.

Ownership: Why It Matters for Users

Every application needs clear ownership to support rotations, permission review, and incident handling. During request flow, expect ownership rules to enforce minimum maintainers.

• Add co-owners early to avoid submission or approval delays

• Ownership checks can trigger governance notifications if requirements are not met

• Some administrator assignments may be applied automatically by policy

• Tenant default administrators help keep newly created or imported applications manageable even when individual owners change roles

Impact: Strong ownership setup improves approval speed and reduces long-term operational risk for your application.

Application Request Ownership Assignment

API Permissions in an Application Request

Application Requests can include API permissions the new application is expected to need. This gives approvers the full access picture before the application is created. Permission access is still governed through Permission Requests after the application exists, so API access is not silently granted just because the application itself was approved.

• Internal API permissions create Permission Requests for the target application owners to review

• External API permissions create Permission Requests that require administrator review and may require Entra ID consent

• If application approval is not required, the application can be created first and the related Permission Requests remain available for normal review

• If application approval is required, approvers review the requested API permissions together with the application request, while access decisions still follow the Permission Request model

• External API permissions may need an administrator with the right Entra ID role to approve or complete consent

When an administrator approves an external API permission, the Azure change may be performed in that administrator's own context. The administrator should have the required Entra ID roles and consent permissions before approving external API access.

TOPdesk Ticketing

If your tenant has TOPdesk enabled for Application Requests, ticketing can follow the request from submission through approval or rejection. The request form and review dialog show when TOPdesk ticketing is enabled, and the ticket number and link appear after the ticket has been created.

• A TOPdesk incident or change can be created when the application request is submitted

• The ticket badge shows the TOPdesk number and opens TOPdesk when a link is available

• Approval and rejection can update or close the ticket depending on Application Settings

• If a ticket is missing or did not update, administrators should check the selected TOPdesk integration, request settings, and tenant operations logs

TOPdesk ticketing is optional and tenant controlled. When it is disabled, application requests still work normally without a ticket badge or external ticket link.

Recommended User Workflow

1. Start request with accurate app purpose and business justification

2. Complete all required metadata with concrete technical details

3. Select correct environment and responsible team

4. Add required co-owners and verify operational contacts

5. Add API permissions only when they are needed for the initial application design

6. Submit and monitor approvals, permission requests, TOPdesk ticketing, and administrator feedback until completion

Pro tip: The best requests are explicit about owner responsibility, data access intent, and production impact. This reduces review cycles significantly.