App Registrations and Secrets

App registrations are where integrations live, and their credentials are the part that expires. These components let you manage both, and watch the expiry dates before they become outages.

List Applications, Get Application, Create Application, Update Application, Delete Application

Full management of app registrations: display name, sign-in audience, notes, tags, identifier URIs and redirect URIs.

Get Application accepts either the object ID or the client ID, and additionally returns the metadata of all secrets and certificates on the registration.

Add Application Secret

Creates a new client secret. You give it a name and either a validity in months or an exact expiry date.

The secret value is returned in this one response and can never be retrieved again. This is Microsoft's behaviour, not a connector limitation.

Process it within the same flow run — write it to a password manager or key vault. If it is lost, the only route is to create a new secret.

Remove Application Secret

Removes a client secret by its key ID. Together with Add Application Secret this forms a rotation: create the new one, deploy it, then remove the old.

Add Application Certificate

Uploads a public certificate in PEM or Base64 DER format. Existing certificates on the registration are kept.

Add Application Owner

Adds an owner to an app registration.

List Expiring Secrets

Lists secrets across all app registrations with their remaining validity in days, most urgent first. Certificates, service principals and already expired credentials can be included, and a maximum remaining days value narrows the result.

Include service principals if you run SAML or SSO applications. SAML signing certificates sit on the enterprise application, not on the app registration — without this option, the certificates that break single sign-on are exactly the ones you will not see.

Trigger: Secret Expiring

The monitoring trigger for expiring credentials. It runs on a configurable check interval and works with two thresholds, a warning threshold and a shorter escalation threshold. Certificates and service principals can be included in the check.

It has three separate outputs, so each stage can start its own branch:

Output	Fires when
warning	a credential falls below the warning threshold
escalation	a credential falls below the escalation threshold
overdue	a credential has expired

The reason for three outputs is that each stage has a different audience. A warning is information for the owning team, an escalation needs someone to take responsibility, and an expired credential needs attention now.

Before wiring the escalation output to something that creates tickets, run the trigger in your own tenant for a few cycles and confirm how often it reports the same credential. Test first, then automate the part that is hard to undo.

A rotated secret receives a new key ID and is picked up by the check again from then on.