Notifications

Two things queue up for the Ops role: a builder asking for an app to read a registered source, and a builder asking for an app to be shared with a group. Both wait until someone decides. Notifications exist so nobody has to remember to go and look.

What Sprig notifies you about

source_access.requested fires when a builder asks for an app to read a registered source. The request waits in the source-access inbox, and the app cannot read that source until Ops decides.

share.requested fires when a builder asks for an app to be shared with an Entra group. It waits in the share-request queue.

Each event toggles independently, so you can be told about one and not the other. A notification is a prompt, never the record: both request types are durable and visible whether or not any notification arrives.

What a receiver gets

Sprig posts an Adaptive Card. A Teams workflow using the “when a Teams webhook request is received” trigger renders it natively, which is the supported path now that the old Office 365 incoming-webhook connectors are retired.

Any other HTTPS receiver can ignore the card and read the same facts from the sprig object in the payload. Request notifications set event to source_access.requested or share.requested and include app, source or group, requestedBy, and requestId.

The event: test value is emitted only by an explicit Send test action. It uses app: sprig-console, includes the signed-in operator in requestedBy and a generated requestId, and has no source or group.

Configuring it

Sign in to the admin console with the Ops role, then open Settings > Notifications. The page shows the saved URL masked. You can configure, replace, or remove it without ever reading the stored credential back. Each event has its own switch.

Select Send test after saving to make one delivery attempt. The page waits for that attempt and reports a receiver or network failure. Event switches do not suppress an explicit test.

For automation, put only the trigger URL in a file created with a secure editor or password manager. Then run:

sprig admin login
chmod 600 notification-webhook
sprig admin set-notifications --webhook-url-file notification-webhook

Delete the file after the command succeeds. The file option keeps the credential out of process listings and shell history.

Webhook setup requires an installation configured with an apps domain. Sprig refuses --webhook-url-file on a domainless installation. Configure an apps domain before setting a webhook. Event toggles and --clear-webhook remain available.

Turn an event off with --no-source-access or --no-share. Stop sending entirely with --clear-webhook. To see the current state, sprig admin get-notifications prints it with the URL masked.

The console and CLI operations require the Ops role.

Treat the webhook URL as a credential

Anyone holding that URL can post into your channel. Sprig stores it securely, exposes only the masked scheme and host, and never writes the full URL to logs or telemetry. Rotating it means generating a new trigger URL in your workflow and setting it again; there is no way to recover the stored value through Sprig.

The receiver must resolve to a public internet address. Sprig refuses redirects and blocks local, private, link-local, and platform metadata destinations. This prevents the credential field from being used to reach services inside the platform network.

Delivery, stated honestly

Best effort and at most once. Sprig makes one attempt with a five-second timeout. It records a failed or capacity-dropped delivery in platform telemetry, but never retries or replays the POST. One attempt avoids sending a duplicate after an ambiguous timeout where the receiver may already have accepted the request.

So do not use notifications as an audit trail. The audit records and the two inboxes are the source of truth; the notification is only the tap on the shoulder.