Customize signup page using api.signuporsignin and custom policies - azure-ad-b2c

Question

I am using api.signuporsignin on my journey and have customized the login page, but when I clic on signup link, it goes to MS default signup page instead of a custom signup. I saw this link goes to
https://tenant.b2clogin.com/tenant.onmicrosoft.com/B2C_1A_signup_signin/api/CombinedSigninAndSignup/unified?local=signup...
Is there a way to customize the signup page using api.signuporsignin?
Here's my journey
<UserJourney Id="SignUpWithEmailOrSignInWithUsernameOrEmail">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
<ClaimsProviderSelections>
<ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninUsernameExchange" />
</ClaimsProviderSelections>
<ClaimsExchanges>
<ClaimsExchange Id="LocalAccountSigninUsernameExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Username" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
</ClaimsExchanges>
</OrchestrationStep>
...
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Username">
<DisplayName>Local Account Signin with Username</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="SignUpTarget">SignUpWithLogonUsernameExchange</Item>
<Item Key="setting.operatingMode">Username</Item>
<Item Key="ContentDefinitionReferenceId">api.selfasserted.test</Item>
</Metadata>
thanks
EDIT 1: Add content definition. I could customize signin page but not signup. When you clic on signup now link, the default MS page appears
<ContentDefinitions>
<ContentDefinition Id="api.signuporsignin">
<LoadUri>https://something.blob.core.windows.net/mycontainer/custom-ui.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0</DataUri>
<Metadata>
<Item Key="DisplayName">Signin and Signup</Item>
</Metadata>
</ContentDefinition>
<ContentDefinition Id="api.selfasserted.test">
<LoadUri>https://something.blob.core.windows.net/mycontainer/custom-signup.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:selfasserted:1.1.0</DataUri>
<Metadata>
<Item Key="DisplayName">Collect information from user page</Item>
</Metadata>
</ContentDefinition>
</ContentDefinitions>

Answer 1

Have a look at your trust framework base definitions and the (unposted) rest of your user journey.
The sign-up or sign in page only provides the links to the "sign up" page - which works by basically skipping the orchestration step. A second orchestration step after the sign-up or sign in page will generally test if a user object ID claim exists (e.g. - if the user actually logged in or not), and then run a sign-up step with a separate content definition if the user is trying to sign up and not sign in...
For example, in the base policies provided by MS:
<UserJourney Id="SignUpOrSignIn">
<OrchestrationSteps>
<!-- Present the sign up or sign in page, with `api.signuporsignin` -->
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
<ClaimsProviderSelections>
<ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
</ClaimsProviderSelections>
<ClaimsExchanges>
<ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
</ClaimsExchanges>
</OrchestrationStep>
<!--
If the previous step did not generate a user object ID (IE -
sign the user in), show the sign up page.
The `LocalAccountSignUpWithLogonEmail` technical profile
should use a diffrent content definion because it's a self-assert
profile - in this case `api.localaccountsignup` - You'll need to
customize this content definition too.
-->
<OrchestrationStep Order="2" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
</ClaimsExchanges>
</OrchestrationStep>
...

Answer 2

As #Allen Wu suggested,searching for the 'api.signuporsignin' in TrustFrameworkExtensions.xml,check if Loaduri is consistent with the url you set in your Azure AD protal->storge account ->container.
<ContentDefinition Id="api.signuporsignin">
<LoadUri>https://storage1.blob.core.windows.net/root/custom-ui.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0</DataUri>
<Metadata>
<Item Key="DisplayName">Signin and Signup</Item>
</Metadata>
<LocalizedResourcesReferences MergeBehavior="Prepend">
<LocalizedResourcesReference Language="en" LocalizedResourcesReferenceId="api.signuporsignin.en" />
<LocalizedResourcesReference Language="es" LocalizedResourcesReferenceId="api.signuporsignin.es" />
</LocalizedResourcesReferences>
</ContentDefinition>