CIAM custom extensions not receiving sign in email in submit event

Question

CIAM custom extensions not receiving sign in email in submit event

Richard Collins 21

Functions written in C# and invoked through custom extensions for start and submit functions can be invoked separately and execute but fail if together and will not surface email so are forced to end. A combined start submit function will error with token issues.

Title:

CIAM Custom Authentication Extensions – Submit event payload missing sign‑in identifier (email), causing failure to complete sign‑up. Extensions intermittently fail to invoke. Requires backend reprovisioning.

Tenant ID:

8299aefb-503c-48f5-bc8c-293d6acdf888

Regions involved:

UK South / UK West (External ID)

Summary

We are implementing Custom Authentication Extensions for a CIAM External Identities user flow (PPXMFlow). Two extensions are configured:

BeforeCollectingAttributes
AfterAttributeCollectionSubmit

Each extension points to a C# Azure Function running on Premium Windows Plan.

✔ The BEFORE extension (Start) works reliably.

❌ Even when the extension returns “Continue”, CIAM still fails because the backend cannot continue without the identifier.

This behavior aligns with recent changes in UK Azure regions affecting External ID tenants (late 2025 / early 2026 rollouts).

Observed Behaviour

1. BEFORE extension works

Function receives the event: microsoft.graph.authenticationEvent.attributeCollectionStart
Returns { "version":"1.0.0", "action":"Continue" }
CIAM proceeds to metadata screen.

2. AFTER extension intermittently fails with:

AADSTS1100001: Non-retryable error has occurred.

Underlying error code: 1003009

No function invocation recorded
Indicates CIAM failed token acquisition for the wizard‑generated Resource Application

This only happens for the Submit extension, not the Start extension.

3. **When AFTER extension does invoke, the payload is missing ALL user identifier data**

Diagnostic logs show:

keys-authCtx=correlationId,client,protocol,clientServicePrincipal,resourceServicePrincipal

keys-dataUser=

keys-attributes=

email.path=<none>

Meaning:

No authenticationContext.user
No authenticationContext.signInName
No data.user
No data.user.identities
No data.attributes.email

This occurs even though the sign-in email is shown at the top of the metadata page and Email is enabled as a sign‑in identifier.

CIAM is suppressing the identifier in the backend Submit event.

This prevents us from completing the sign‑up even when the extension returns "action": "Continue".

Expected Behaviour

In a healthy CIAM tenant:

AFTER extension receives the sign‑in identifier (email) in:
- data.authenticationContext.user.signInName, or
- data.user.identities[*].issuerAssignedId, or
- data.attributes.email (if collected)

This previously worked for other function apps in this tenant, and works in other tenants.

Summary of Issue

This appears to be the known issue where:

Wizard‑generated Resource Applications (e.g., getoutapp00Y) are not fully provisioned in CIAM backend → results in 1003009
AFTER event payload does not include the sign‑in identifier even when Email is the sign‑in identifier and is displayed in the UI
Known problem in UK South / UK West External Identities tenants during late‑2025 / early‑2026 CIAM backend rollout

This is not caused by function code or configuration.

It is a tenant backend provisioning and routing issue.

What We Need Microsoft to Do

Please:

1. Re‑provision the Custom Authentication Extensions backend for this tenant, including:

Event routing
Resource Application creation for Submit extension
Token acquisition mapping
Backend policies controlling inclusion of sign‑in identifier in Submit events

2. Enable / restore the backend flag for this tenant:

Return sign‑in identifier (email) inside AfterAttributeCollectionSubmit events

(This is the same flag that was present in earlier builds and is required to complete the sign‑up pipeline.)

Without this, our AFTER extension cannot receive the necessary user identifier to complete the sign‑up process.

Why this is urgent

The CIAM sign‑up pipeline cannot complete because:

Email is missing from Submit events
Submit extension intermittently fails to invoke (1003009)
CIAM UI shows “Something went wrong”
End‑users cannot onboard

Richard Collins 21 Reputation points

2026-03-17T23:28:47.2666667+00:00
The issue appeared to be because claims processing had been referenced in the submit app.

When this was stripped out and a minimal change 'modifyAttributeValue' was used the stalled signup submit is an error.

Here is a tight, accurate, support‑ready technical note you can give directly to your Microsoft Support Engineer. It explains exactly what we changed, why it is valid, and why the error is now outside the Azure Function despite successful Start/Submit execution.

No extra detail. No claims logic. No Dataverse. Just the minimal, Microsoft‑approved Submit action and the observed failure.

Technical Summary for Microsoft Support Engineer

Issue: Sign‑up fails with “Something went wrong” after Attribute Collection Submit, despite both Start and Submit extensions succeeding

Environment

Microsoft Entra External ID (customer tenant)

Custom authentication extensions:

OnAttributeCollectionStart → Azure Function (“HttpTriggerCIAMstart”)

OnAttributeCollectionSubmit → Azure Function (“HttpTriggerCIAMsubmit”)

Both functions return HTTP 200 and appear as Succeeded in the Function App logs.

The built‑in attribute collection UI renders correctly and a custom attribute IRSAccessLevel is displayed on the form.

Signup fails immediately after submit with: AADSTS1100001 underlying error code: 1003002 even though the Submit function completed successfully.

What changed (minimal tested modification)

Only one modification was made in the Submit extension:

**We now include ONE supported OnAttributeCollectionSubmit action:

modifyAttributeValues**

This replaces the original “Submit that does nothing” sample with a version that writes a collected attribute.

Action used (supported & documented):

microsoft.graph.attributeCollectionSubmit.modifyAttributeValues ✔ Listed in Microsoft docs for the Submit event. ✔ Valid modification action for attribute collection flows.

NO unsupported actions were added (e.g., no setUserClaims, no showBlockPage, no modify schemas).

Minimal Submit Function (exact code in production)

#r "Newtonsoft.Json"

using Microsoft.AspNetCore.Mvc;

using Newtonsoft.Json;

using System.Collections.Generic;

using System.IO;

using System.Threading.Tasks;

using System.Net;

public static async Task<object> Run(HttpRequest req, ILogger log)

{

    _ = await new StreamReader(req.Body).ReadToEndAsync();

    var actions = new List<object>

    {

        new ModifyAttributeValues {

            type = "microsoft.graph.attributeCollectionSubmit.modifyAttributeValues",

            attributes = new Dictionary<string, object> {

                {

                    "IRSAccessLevel",

                    new Dictionary<string, object> {

                        { "value", "L1Basic" }

                    }

                }

            }

        },

        new ContinueWithDefaultBehavior {

            type = "microsoft.graph.attributeCollectionSubmit.continueWithDefaultBehavior"

        }

    };

    return new JsonResult(new Envelope {

        data = new SubmitData {

            type = "microsoft.graph.onAttributeCollectionSubmitResponseData",

            actions = actions

        }

    }) { StatusCode = (int)HttpStatusCode.OK };

}

public class Envelope { public SubmitData data { get; set; } }

public class SubmitData

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

    public List<object> actions { get; set; }

}

public class ModifyAttributeValues

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

    [JsonProperty("attributes")]

    public Dictionary<string, object> attributes { get; set; }

}

public class ContinueWithDefaultBehavior

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

}

Notes:

The code uses only supported Microsoft types.

The returned JSON conforms to the published OnAttributeCollectionSubmit schema.

Attribute value structure { "value": "<string>" } mirrors Microsoft’s own documentation examples for attribute modification.

No claims, tokens, identity overrides, or experimental actions are used.

Only one attribute is being overwritten: IRSAccessLevel.

Observed Behavior

Start function invoked successfully.

Submit function invoked successfully (HTTP 200, duration ~60ms).

CIAM displays the attribute collection page including IRSAccessLevel.

After clicking Next, CIAM immediately returns: AADSTS1100001 Underlying error: 1003002

No failure occurs inside the Azure Function (no exceptions, no 500s).

Meaning of AADSTS1100001 / 1003002

Per Microsoft documentation and internal diagnostic behavior:

1003002 = CIAM rejected the response during schema validation or user object write‑back.

This occurs after:

the extension returns 200

actions are accepted syntactically

the identity provider attempts to finalize user creation

In other words:

Start and Submit succeeded, but CIAM fails during the internal directory write stage.

This stage validates:

identity hydration (issuerAssignedId)

attribute schema consistency

directory constraints

mandatory field population

Key diagnostic observation

Earlier captured diagnostic payloads (from a full Start logger) showed:

data.userSignUpInfo.identities[0].issuerAssignedId = null

If CIAM does not hydrate the user identity correctly after the code verification step, the subsequent directory write will fail — even when the Submit extension succeeds — producing the exact behavior we see now.

This is consistent with known behavior in some UK region tenants.

Request to Microsoft Support

Please investigate the CIAM backend identity hydration during the Attribute Collection flow in tenant:

Tenant ID: (provide)

Correlation ID sample: a7ef4814-9e6c-456d-889a-d1e2c68546f1

Request ID sample: d0e955d7-0076-4ecf-b6eb-9cdadd990200

Timestamp: 2026‑03‑17T23:05:44Z

Error: AADSTS1100001 / underlying error code 1003002

Both Start and Submit custom authentication extensions return valid HTTP 200 responses.

The Submit response contains only officially supported actions:

modifyAttributeValues

continueWithDefaultBehavior

Ask Support to confirm:

Whether userSignUpInfo.identities[*].issuerAssignedId is being hydrated after email verification.

Whether the Submit flow is failing during directory write, due to missing identity or attribute schema incompatibility.

Whether the tenant needs a backend flag enabled (known in some regions):

SignInIdentifierHydrationFix

ReturnSignInIdentifierInExtensions

If you want, I can convert this into a PDF-style, bullet‑pointed, or email‑ready version.

Just say “format for email” or “format for PDF”.Here is a tight, accurate, support‑ready technical note you can give directly to your Microsoft Support Engineer.

It explains exactly what we changed, why it is valid, and why the error is now outside the Azure Function despite successful Start/Submit execution.

No extra detail. No claims logic. No Dataverse. Just the minimal, Microsoft‑approved Submit action and the observed failure.

Technical Summary for Microsoft Support Engineer

Issue: Sign‑up fails with “Something went wrong” after Attribute Collection Submit, despite both Start and Submit extensions succeeding

Environment

Microsoft Entra External ID (customer tenant)

Custom authentication extensions:

OnAttributeCollectionStart → Azure Function (“HttpTriggerCIAMstart”)

OnAttributeCollectionSubmit → Azure Function (“HttpTriggerCIAMsubmit”)

Both functions return HTTP 200 and appear as Succeeded in the Function App logs.

The built‑in attribute collection UI renders correctly and a custom attribute IRSAccessLevel is displayed on the form.

Signup fails immediately after submit with: AADSTS1100001
underlying error code: 1003002
even though the Submit function completed successfully.

What changed (minimal tested modification)

Only one modification was made in the Submit extension:

**We now include ONE supported OnAttributeCollectionSubmit action:

modifyAttributeValues**

This replaces the original “Submit that does nothing” sample with a version that writes a collected attribute.

Action used (supported & documented):

microsoft.graph.attributeCollectionSubmit.modifyAttributeValues
✔ Listed in Microsoft docs for the Submit event.
✔ Valid modification action for attribute collection flows.

NO unsupported actions were added (e.g., no setUserClaims, no showBlockPage, no modify schemas).

Minimal Submit Function (exact code in production)

#r "Newtonsoft.Json"

using Microsoft.AspNetCore.Mvc;

using Newtonsoft.Json;

using System.Collections.Generic;

using System.IO;

using System.Threading.Tasks;

using System.Net;

public static async Task<object> Run(HttpRequest req, ILogger log)

{

    _ = await new StreamReader(req.Body).ReadToEndAsync();

    var actions = new List<object>

    {

        new ModifyAttributeValues {

            type = "microsoft.graph.attributeCollectionSubmit.modifyAttributeValues",

            attributes = new Dictionary<string, object> {

                {

                    "IRSAccessLevel",

                    new Dictionary<string, object> {

                        { "value", "L1Basic" }

                    }

                }

            }

        },

        new ContinueWithDefaultBehavior {

            type = "microsoft.graph.attributeCollectionSubmit.continueWithDefaultBehavior"

        }

    };

    return new JsonResult(new Envelope {

        data = new SubmitData {

            type = "microsoft.graph.onAttributeCollectionSubmitResponseData",

            actions = actions

        }

    }) { StatusCode = (int)HttpStatusCode.OK };

}

public class Envelope { public SubmitData data { get; set; } }

public class SubmitData

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

    public List<object> actions { get; set; }

}

public class ModifyAttributeValues

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

    [JsonProperty("attributes")]

    public Dictionary<string, object> attributes { get; set; }

}

public class ContinueWithDefaultBehavior

{

    [JsonProperty("@odata.type")]

    public string type { get; set; }

}

Notes:

The code uses only supported Microsoft types.

The returned JSON conforms to the published OnAttributeCollectionSubmit schema.

Attribute value structure { "value": "<string>" } mirrors Microsoft’s own documentation examples for attribute modification.

No claims, tokens, identity overrides, or experimental actions are used.

Only one attribute is being overwritten: IRSAccessLevel.

Observed Behavior

Start function invoked successfully.

Submit function invoked successfully (HTTP 200, duration ~60ms).

CIAM displays the attribute collection page including IRSAccessLevel.

After clicking Next, CIAM immediately returns: AADSTS1100001
Underlying error: 1003002

No failure occurs inside the Azure Function (no exceptions, no 500s).

Meaning of AADSTS1100001 / 1003002

Per Microsoft documentation and internal diagnostic behavior:

1003002 = CIAM rejected the response during schema validation or user object write‑back.

This occurs after:

the extension returns 200

actions are accepted syntactically

the identity provider attempts to finalize user creation

In other words:

Start and Submit succeeded, but CIAM fails during the internal directory write stage.

This stage validates:

identity hydration (issuerAssignedId)

attribute schema consistency

directory constraints

mandatory field population

Key diagnostic observation

Earlier captured diagnostic payloads (from a full Start logger) showed:

data.userSignUpInfo.identities[0].issuerAssignedId = null

If CIAM does not hydrate the user identity correctly after the code verification step, the subsequent directory write will fail — even when the Submit extension succeeds — producing the exact behavior we see now.

This is consistent with known behavior in some UK region tenants.

Request to Microsoft Support

Please investigate the CIAM backend identity hydration during the Attribute Collection flow in tenant:

Tenant ID: (provide)

Correlation ID sample: a7ef4814-9e6c-456d-889a-d1e2c68546f1

Request ID sample: d0e955d7-0076-4ecf-b6eb-9cdadd990200

Timestamp: 2026‑03‑17T23:05:44Z

Error: AADSTS1100001 / underlying error code 1003002

Both Start and Submit custom authentication extensions return valid HTTP 200 responses.

The Submit response contains only officially supported actions:

modifyAttributeValues

continueWithDefaultBehavior

Ask Support to confirm:

Whether userSignUpInfo.identities[*].issuerAssignedId is being hydrated after email verification.

Whether the Submit flow is failing during directory write, due to missing identity or attribute schema incompatibility.

Whether the tenant needs a backend flag enabled (known in some regions):

SignInIdentifierHydrationFix

ReturnSignInIdentifierInExtensions
Shubham Sharma 15,500 Reputation points Microsoft External Staff Moderator

2026-03-23T06:16:30.4766667+00:00
Hey Richard – thanks for all the deep dive here. From everything you’ve shared, it looks like you’re running into the known CIAM backend provisioning bug in UK South/UK West where:

• The wizard-generated resource app for your OnAttributeCollectionSubmit extension isn’t fully provisioned

• CIAM fails to acquire a token for that app (AADSTS1100001 / 1003009 or 1003002)

• As a result, the Submit payload comes back with no signInName, no data.user.identities, no data.attributes.email, and the flow bails out with “Something went wrong”

Because your Functions are returning HTTP 200 and you only have the officially supported actions (modifyAttributeValues + continueWithDefaultBehavior), we can rule out any code/config issue on your side. This is a tenant-level routing/provisioning hiccup in the CIAM backend.

What you (or your Microsoft support engineer) will need to do:

Re-provision the Custom Authentication Extensions backend for your tenant – Recreate or fully provision the wizard-generated Resource Application for the Submit extension – Refresh event routing and token acquisition mapping – Ensure the backend policies around including the sign-in identifier in AfterAttributeCollectionSubmit are in place

Re-enable the backend flag that returns the sign-in identifier (email) in Submit events (aka the “ReturnSignInIdentifierInExtensions” or equivalent flag that existed in earlier builds)

Once that’s done, your Submit event will include the user’s email/identities again, CIAM can complete its directory write, and the sign-up will succeed.

Next steps:

• If you haven’t already, grab a sample Correlation ID, Request ID and timestamp from a failed run so your support engineer can escalate directly to the CIAM service team.

• Confirm you’re only using the two minimal Submit actions (modifyAttributeValues + continueWithDefaultBehavior).

References

Custom authentication extensions overview (OnAttributeCollectionStart & Submit) https://learn.microsoft.com/entra/external-id/customers/concept-custom-extensions

Create a custom authentication extension for attribute-collection events https://learn.microsoft.com/entra/identity-platform/custom-extension-attribute-collection

Extend authentication flows with your own business logic https://learn.microsoft.com/entra/external-id/customers/concept-custom-extensions#attribute-collection-start-and-submit-events

Microsoft Entra External ID (CIAM) overview https://learn.microsoft.com/azure/active-directory/external-identities/customers/overview-customers-ciam

Let us know the above steps helps.

Thanks
Shubham Sharma 15,500 Reputation points Microsoft External Staff Moderator

2026-03-25T03:55:36.18+00:00

Richard Collins

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.

1 answer

Your answer

Shubham Sharma 15,500 Reputation points Microsoft External Staff Moderator

2026-03-25T03:55:36.18+00:00

Richard Collins

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.

Answer 1

Hey Richard – this looks like the known CIAM backend provisioning bug in UK South/UK West. Because both your Start and Submit functions return HTTP 200 and only use supported actions (modifyAttributeValues + continueWithDefaultBehavior), the issue isn’t in your code but in the CIAM backend:

• The wizard-generated resource app for your OnAttributeCollectionSubmit extension isn’t fully provisioned → CIAM can’t acquire a token (AADSTS1100001 / 1003009 or 1003002) → the Submit event sometimes never fires.

• When it does fire, CIAM suppresses the sign-in identifier in the payload (no signInName, no data.user.identities, etc.), so the flow fails on the “metadata” screen.

What to do next:

Re-provision your tenant’s custom authentication extensions backend
- Fully provision (or recreate) the wizard-generated Resource Application for the Submit extension
- Refresh event routing and token-acquisition mapping
- Ensure the backend flag that returns the sign-in identifier (email) in AfterAttributeCollectionSubmit is turned back on
Capture a failing run’s Correlation ID, Request ID and Timestamp, then open a ticket with Microsoft Support. Reference the errors (AADSTS1100001 / 1003009 or 1003002), your Tenant ID, and sample IDs so the CIAM service team can restore the missing provisioning and flag.

Once the backend is reprovisioned and the “ReturnSignInIdentifierInExtensions” flag is reinstated, your Submit payload will include the email again, CIAM can complete its directory write, and the sign-up flow will succeed.

References for your support engineer:

Custom authentication extensions overview https://learn.microsoft.com/entra/external-id/customers/concept-custom-extensions
Create a custom extension for attribute-collection start & submit events https://learn.microsoft.com/entra/identity-platform/custom-extension-attribute-collection
Extend authentication flows with your own business logic https://learn.microsoft.com/entra/external-id/customers/concept-custom-extensions#attribute-collection-start-and-submit-events

Let me know once you have your IDs or if you need any more help pushing this through Support!

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Share via

CIAM custom extensions not receiving sign in email in submit event

📩 Support Ticket Text — CIAM Custom Authentication Extensions Not Receiving Sign‑in Email in Submit Event (Tenant Routing/Provisioning Failure)

Summary

✔ The BEFORE extension (Start) works reliably.

❌ The AFTER extension (Submit) intermittently fails and, when invoked, does not contain the user’s sign‑in email or user object in the payload.

❌ As a result, the sign‑up process cannot complete — CIAM shows “Something went wrong” on the metadata screen.

❌ Even when the extension returns “Continue”, CIAM still fails because the backend cannot continue without the identifier.

Observed Behaviour

1. BEFORE extension works

2. AFTER extension intermittently fails with:

3. When AFTER extension does invoke, the payload is missing ALL user identifier data

Expected Behaviour

Summary of Issue

What We Need Microsoft to Do

1. Re‑provision the Custom Authentication Extensions backend for this tenant, including:

2. Enable / restore the backend flag for this tenant:

Why this is urgent

Technical Summary for Microsoft Support Engineer

Issue: Sign‑up fails with “Something went wrong” after Attribute Collection Submit, despite both Start and Submit extensions succeeding

Environment

What changed (minimal tested modification)

**We now include ONE supported OnAttributeCollectionSubmit action:

Action used (supported & documented):

Minimal Submit Function (exact code in production)

Notes:

Observed Behavior

Meaning of AADSTS1100001 / 1003002

1003002 = CIAM rejected the response during schema validation or user object write‑back.

Key diagnostic observation

Request to Microsoft Support

Ask Support to confirm:

Technical Summary for Microsoft Support Engineer

Issue: Sign‑up fails with “Something went wrong” after Attribute Collection Submit, despite both Start and Submit extensions succeeding

Environment

What changed (minimal tested modification)

**We now include ONE supported OnAttributeCollectionSubmit action:

Action used (supported & documented):

Minimal Submit Function (exact code in production)

Notes:

Observed Behavior

Meaning of AADSTS1100001 / 1003002

1003002 = CIAM rejected the response during schema validation or user object write‑back.

Key diagnostic observation

Request to Microsoft Support

Ask Support to confirm:

1 answer

Your answer

3. **When AFTER extension does invoke, the payload is missing ALL user identifier data**