commit

Co-authored-by: Copilot <copilot@github.com>

Author: Tejasri-Microsoft

azure.yaml

@@ -9,14 +9,3 @@ requiredVersions:
 metadata:
   template: content-processing@1.0
   name: content-processinge@1.0
-
-hooks:
-  postprovision:
-    posix:
-      shell: sh
-      run: sed -i 's/\r$//' ./infra/scripts/post_deployment.sh; bash ./infra/scripts/post_deployment.sh
-      interactive: true
-    windows:
-      shell: pwsh
-      run: ./infra/scripts/post_deployment.ps1
-      interactive: true

azure_custom.yaml

@@ -64,13 +64,3 @@ services:
       registry: ${AZURE_CONTAINER_REGISTRY_ENDPOINT}
       remoteBuild: true
 
-hooks:
-  postprovision:
-    posix:
-      shell: sh
-      run: sed -i 's/\r$//' ./infra/scripts/post_deployment.sh; bash ./infra/scripts/post_deployment.sh
-      interactive: true
-    windows:
-      shell: pwsh
-      run: ./infra/scripts/post_deployment.ps1
-      interactive: true

docs/AVMPostDeploymentGuide.md

@@ -14,7 +14,7 @@ After successfully deploying the Content Processing Solution Accelerator using t
 2. **Process sample files** — upload and process sample claim bundles for verification
 3. **Configure authentication** — set up app registration for secure access
 
-> **Note:** When deploying via `azd up`, schema registration and sample processing happen automatically through a post-provisioning hook. AVM deployments require the manual steps below.
+> **Note:** Post-deployment data setup and authentication are manual steps for both `azd` and AVM deployments. Run the scripts in this guide after infrastructure provisioning.
 
 ## Prerequisites
 
@@ -85,7 +85,7 @@ The workflow for each bundle:
 
 You can perform these steps via the web UI or the API directly. See the [API documentation](./API.md) and [Golden Path Workflows](./GoldenPathWorkflows.md) for details.
 
-> **Note:** When deploying via `azd up`, sample file processing happens automatically as Step 4 of the post-provisioning hook.
+> **Note:** In `azd` and AVM flows, sample file processing runs when you execute the post-deployment script manually.
 
 ### Step 5: Configure Authentication (Required)
 

docs/ConfigureAppAuthentication.md

@@ -1,15 +1,17 @@
 # Set up Authentication in Azure Container App
 
-> ### ✅ Automatic configuration is now the default
+> ### ✅ Recommended: run the authentication script first
 >
-> As of the latest release, `azd up` **automatically** performs all of the steps below via the `infra/scripts/configure_auth.{sh,ps1}` post-provisioning hook. You should not need to follow this document in most cases.
+> `azd up` no longer runs authentication setup automatically. Run the script below after deployment:
 >
-> See [DeploymentGuide.md § 5.2](./DeploymentGuide.md#52-configure-authentication-automatic) for details, including how to opt out with `azd env set AZURE_SKIP_AUTH_SETUP true`.
+> - Windows: `./infra/scripts/configure_auth.ps1`
+> - macOS/Linux: `sed -i 's/\r$//' ./infra/scripts/configure_auth.sh && bash ./infra/scripts/configure_auth.sh`
 >
-> Follow the manual steps below **only** if:
-> - You set `AZURE_SKIP_AUTH_SETUP=true` before running `azd up`
-> - The automatic script reported an error (most commonly: your identity lacks permission to grant admin consent — a tenant admin still has to consent, but the rest of the configuration is already complete)
+> See [DeploymentGuide.md § 5.2](./DeploymentGuide.md#52-configure-authentication-manual-script) for details.
+>
+> Follow the portal/manual steps below if:
 > - Your tenant policy prohibits programmatic app registration or secret creation
+> - The script reports a permission or policy failure that cannot be resolved in your current identity
 
 This document provides step-by-step instructions to configure Azure App Registrations for the front-end and back-end applications.
 

docs/CustomizeSchemaData.md

@@ -166,7 +166,7 @@ The response returns a Schema `Id` — **save this** for Step 3.
 
 ### Option B: Register via script (batch)
 
-> **Note:** The default sample schemas are registered **automatically** during `azd up` via the post-provisioning hook. You only need to run the script manually if you are adding custom schemas or if automatic registration was skipped.
+> **Note:** Default sample schemas are registered when you run the post-deployment script manually (see Deployment Guide Step 5.1). Run this script again whenever you add or update schemas.
 
 For bulk registration, use the provided script with a JSON manifest. The script performs three steps automatically:
 1. **Registers** individual schema files via `/schemavault/`

docs/DeploymentGuide.md

@@ -301,149 +301,100 @@ azd up
 
 ## Step 5: Post-Deployment Configuration
 
-### 5.1 Schema Registration (Automatic)
+### 5.1 Run Schema Registration (Manual)
 
- > Want to customize the schemas for your own documents? [Learn more about adding your own schemas here.](./CustomizeSchemaData.md)
+> Want to customize the schemas for your own documents? [Learn more about adding your own schemas here.](./CustomizeSchemaData.md)
 
-Schema registration happens **automatically** as part of the `azd up` post-provisioning hook — no manual steps required. After infrastructure is deployed, the hook:
+`azd up` now provisions infrastructure and application containers only. Post-provision data setup is split into **separate manual steps** so you can run, retry, or skip them independently.
 
-1. Waits for the API container app to be ready
-2. Registers the sample schema files (auto claim, damaged car image, police report, repair estimate)
-3. Creates an **"Auto Claim"** schema set
-4. Adds all registered schemas into the schema set
-5. Processes sample file bundles (`claim_date_of_loss/` and `claim_hail/`) — creates claim batches, uploads files with their mapped schemas, and submits them for processing
+Run schema registration first to:
 
-After successful deployment, the terminal displays container app details and schema registration output:
+1. Wait for the API container app to be ready
+2. Register the sample schema files (auto claim, damaged car image, police report, repair estimate)
+3. Create the **"Auto Claim"** schema set
+4. Add all registered schemas into the schema set
 
-```
-🧭 Web App Details:
-  ✅ Name: ca-<env>-web
-  🌐 Endpoint: ca-<env>-web.<region>.azurecontainerapps.io
-  🔗 Portal URL: https://portal.azure.com/#resource/...
-
-🧭 API App Details:
-  ✅ Name: ca-<env>-api
-  🌐 Endpoint: ca-<env>-api.<region>.azurecontainerapps.io
-  🔗 Portal URL: https://portal.azure.com/#resource/...
-
-🧭 Workflow App Details:
-  ✅ Name: ca-<env>-wkfl
-  🔗 Portal URL: https://portal.azure.com/#resource/...
-
-📦 Registering schemas and creating schema set...
-  ⏳ Waiting for API to be ready...
-  ✅ API is ready.
-============================================================
-Step 1: Register schemas
-============================================================
-✓ Successfully registered: Auto Insurance Claim Form's Schema Id - <id>
-✓ Successfully registered: Damaged Vehicle Image Assessment's Schema Id - <id>
-✓ Successfully registered: Police Report Document's Schema Id - <id>
-✓ Successfully registered: Repair Estimate Document's Schema Id - <id>
-
-============================================================
-Step 2: Create schema set
-============================================================
-✓ Created schema set 'Auto Claim' with ID: <id>
-
-============================================================
-Step 3: Add schemas to schema set
-============================================================
-  ✓ Added 'AutoInsuranceClaimForm' (<id>) to schema set
-  ✓ Added 'DamagedVehicleImageAssessment' (<id>) to schema set
-  ✓ Added 'PoliceReportDocument' (<id>) to schema set
-  ✓ Added 'RepairEstimateDocument' (<id>) to schema set
-
-============================================================
-Schema registration process completed.
-  Schema set ID: <id>
-  Schemas added: 4
-============================================================
-
-============================================================
-Step 4: Process sample file bundles
-============================================================
-
-  📂 Processing bundle: claim_date_of_loss
-    ✅ Claim batch created with ID: <id>
-    ✅ Uploaded 'claim_form.pdf' successfully.
-    ✅ Uploaded 'damage_photo.png' successfully.
-    ✅ Uploaded 'police_report.pdf' successfully.
-    ✅ Uploaded 'repair_estimate.pdf' successfully.
-    ✅ Claim batch '<id>' submitted for processing.
-
-  📂 Processing bundle: claim_hail
-    ✅ Claim batch created with ID: <id>
-    ✅ Uploaded 'claim_form.pdf' successfully.
-    ✅ Uploaded 'damage_photo.png' successfully.
-    ✅ Uploaded 'repair_estimate.pdf' successfully.
-    ✅ Claim batch '<id>' submitted for processing.
-
-============================================================
-Sample file processing completed.
-============================================================
-```
+**Windows (PowerShell):**
 
-### 5.2 Configure Authentication (Automatic)
+```powershell
+./infra/scripts/register_schemas.ps1
+```
 
-Starting with this release, authentication is configured **automatically** as part of the `azd up` post-provisioning hook. The hook:
+**macOS/Linux:**
 
-1. Creates two Entra ID app registrations (`<env>-web-app`, `<env>-api-app`) with the correct redirect URIs, exposed scopes, and required permissions
-2. Grants admin consent (best effort — see note below)
-3. Mints client secrets and stores them in Container Apps secrets
-4. Enables the Microsoft identity provider on both the Web and API container apps
-5. Restricts the API to only accept tokens from the Web app (`allowedApplications`)
-6. Sets the `APP_WEB_CLIENT_ID`, `APP_WEB_SCOPE`, `APP_API_SCOPE`, and `APP_AUTH_ENABLED` environment variables on the Web container
+```bash
+sed -i 's/\r$//' ./infra/scripts/register_schemas.sh
+bash ./infra/scripts/register_schemas.sh
+```
 
-You will see an **`🔐 Configuring Entra ID authentication`** section in the `azd up` output, ending with a summary of both client IDs and scopes.
+The script is idempotent and safe to re-run.
 
-> **Note:** EasyAuth can take up to 10 minutes to fully propagate. If the Web app returns 500/401 immediately after deployment, wait a few minutes and retry.
+### 5.2 Run Sample Data Upload (Manual)
 
-#### When automatic configuration is not possible
+After schema registration completes, upload the sample bundles as a separate explicit step. This step:
 
-Automatic configuration requires permission to:
-- Create Entra ID app registrations (**Application Administrator** or equivalent)
-- Grant admin consent for delegated permissions (**Cloud Application Administrator** or **Global Administrator**)
+1. Resolves the existing **Auto Claim** schema set and registered schema IDs
+2. Creates sample claim batches for `claim_date_of_loss` and `claim_hail`
+3. Uploads each file with its mapped schema
+4. Submits each claim batch for processing
 
-If your identity cannot grant admin consent, the script prints a clear manual action message like:
+**Windows (PowerShell):**
 
+```powershell
+./infra/scripts/upload_sample_data.ps1
 ```
-⚠️ Admin consent failed. Sign-in may fail until a tenant admin runs:
-     az ad app permission admin-consent --id <web-client-id>
-   Or visit: https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<web-client-id>
+
+**macOS/Linux:**
+
+```bash
+sed -i 's/\r$//' ./infra/scripts/upload_sample_data.sh
+bash ./infra/scripts/upload_sample_data.sh
 ```
 
-In that case, share the command/URL with your tenant administrator.
+### 5.3 Configure Authentication (Manual Script)
+
+Run authentication setup as an explicit step after post-deployment data setup:
+
+**Windows (PowerShell):**
 
-#### Skipping automatic auth configuration
+```powershell
+./infra/scripts/setup_auth.ps1
+```
 
-If your tenant blocks programmatic app registration, or you prefer to configure authentication manually, disable the automation before running `azd up`:
+**macOS/Linux:**
 
 ```bash
-azd env set AZURE_SKIP_AUTH_SETUP true
+sed -i 's/\r$//' ./infra/scripts/setup_auth.sh
+bash ./infra/scripts/setup_auth.sh
 ```
 
-Then follow the manual instructions: [App Authentication Configuration (manual)](./ConfigureAppAuthentication.md).
+The auth script is idempotent and performs preflight validation before making changes.
+
+#### Required Permissions for auth setup
+
+- Create/update app registrations: **Application Administrator**, **Cloud Application Administrator**, or **Global Administrator**
+- Grant admin consent: **Cloud Application Administrator** or **Global Administrator**
+- Update Container Apps auth/secret settings: **Contributor** on the deployment resource group
 
-#### Re-running
+If permissions are insufficient, the script exits early (or warns before consent) with clear remediation guidance.
 
-The automation is idempotent: re-running `azd up` reuses the existing app registrations (IDs are persisted in `AZURE_AUTH_WEB_CLIENT_ID` / `AZURE_AUTH_API_CLIENT_ID` in the azd environment) and does not rotate client secrets.
+> **Note:** EasyAuth can take up to 10 minutes to fully propagate. If the Web app returns 500/401 immediately after setup, wait a few minutes and retry.
 
 #### WAF (Well-Architected Framework) deployments
 
-The automation is fully compatible with the WAF / production profile (`main.waf.parameters.json`, which enables `enablePrivateNetworking`, `enableRedundancy`, and `enableScalability`). The Web and API container apps keep external ingress in the default WAF profile, so the redirect URIs registered by the script (`https://<fqdn>/.auth/login/aad/callback`) remain the correct public entry points. All script operations use the Azure management plane (Graph + ARM) and are unaffected by the private networking applied to backend resources such as Storage, Cosmos DB, and ACR.
+Authentication script execution is fully compatible with the WAF / production profile (`main.waf.parameters.json`, which enables `enablePrivateNetworking`, `enableRedundancy`, and `enableScalability`). The Web and API container apps keep external ingress in the default WAF profile, so registered redirect URIs (`https://<fqdn>/.auth/login/aad/callback`) remain valid public entry points.
 
-> If you further customize the WAF deployment to make the Web or API container app ingress **internal-only**, automatic configuration still runs, but end-user access to the sign-in page will require reaching the private endpoint (e.g., via the deployed jumpbox or a VPN).
+> If you customize WAF to make Web or API ingress internal-only, run the auth script from an environment that can reach those private endpoints (for example, the deployed jumpbox or a VPN-connected host).
 
-### 5.3 Verify Deployment
+### 5.4 Verify Deployment
 
 1. Access your application using the **Web App Endpoint** from the deployment output.
 2. Confirm the application loads successfully.
 3. Verify you can sign in with your authenticated account.
 
-### 5.4 Test the Application
+### 5.5 Test the Application
 
-> **Note:** The post-deployment hook automatically uploads and processes two sample claim bundles (`claim_date_of_loss` and `claim_hail`). You can verify the results in the web app immediately after deployment.
+> **Note:** If you ran [Step 5.2](#52-run-sample-data-upload-manual), two sample claim bundles (`claim_date_of_loss` and `claim_hail`) should already be processed in the web app.
 
 **Quick Test Steps:**
 1. **Check Processed Results**: Open the web app — you should see the two sample claim batches already processed with extracted data.