10. Production Deployment & Troubleshooting

10.1 What ships automatically (Git + startup, no manual step)

• The 5 new SaaS-side entities/migration (TenantOperationalDefaultItems, TenantOperationalDefaultApplyLogs — purely additive CREATE TABLE, no DROP/ALTER on any existing table) apply automatically at Shumoul.Api startup via the same TenancyDatabaseInitializer pending-migration check every other MultiTenancyApi migration already uses.
• TenantOperationalDefaultItemSeeder runs automatically (gate-free, ICustomSeeder, Priority 40).
• The 16 de-gated ApplicationDbSeeder reference-data steps run automatically for every active tenant at host startup (existing DatabaseInitializer per-tenant provisioning loop) — no new trigger needed.
• The automatic, in-process operational-defaults call inside OnboardingService.ApplyRecommendationAsync requires no configuration — it always runs when a tenant applies their onboarding recommendation, independent of the bridge settings below (a bridge-disabled/misconfigured state is caught, logged as a warning, and never blocks the settings-patch apply).

10.2 What requires configuration (same convention as the Onboarding Apply Bridge)

Setting	Purpose
TenantOperationalDefaultsApplyBridgeSettings:Enabled	Must be true for the operational-defaults apply to write anything — false is the committed, production-safe default
TenantOperationalDefaultsApplyBridgeSettings:BackEndBaseUrl	Same Shumoul.Api instance as every sibling bridge (single-process hosting model — see Onboarding Apply Bridge, Chapter 21 §21.2)
TenantOperationalDefaultsApplyBridgeSettings:InternalApiKey	Shared secret, must exactly equal InternalServiceAuthSettings:TenantOperationalDefaultsApplyApiKey
InternalServiceAuthSettings:TenantOperationalDefaultsApplyApiKey	The BackEnd-side half of the same shared secret

Both are **FROM_ENVIRONMENT** placeholders in the committed appsettings.json/appsettings.Development.json — never a real value committed to git, same convention as every sibling internal key.

10.3 Deployment checklist

• Shumoul.Framework.MultiTenancy.Api on the target server is 1.0.121 or newer.
• BackEnd's PackageReference matches the same version.
• TenantOperationalDefaultsApplyBridgeSettings:Enabled=true and the two InternalApiKey values are set from the platform's secret store (never committed), matching whichever environment (staging vs. production) this deploy targets.
• No migration approval is required beyond the normal deploy — the new tables are purely additive.
• After deploy, a safe read-only check: confirm the log line "Completed seeding tenant operational default items." appears once per startup, and "Completed seeding ... for {tenant} Tenant." lines for the 16 de-gated reference-data steps appear (with Inserted=0 on any already-provisioned tenant) with no accompanying error.
• Do not create a production test tenant or run a live onboarding apply without separate, explicit approval — the same rule as every other framework's deployment guidance in this documentation set.

10.4 Known remaining gaps

• CashAccountCurrency/BankAccountCurrency GL-currency linking is not implemented — closed by the Cash/Bank GL-Currency Linking phase, which extends the accounting-chart-template mapping-apply flow (CashOnHand/BankAccount mapping keys) to resolve and create these links once both a chart template and this phase's operational defaults exist for the tenant. Chapter 5 §5.2 is retained as-is for historical context (why it was deliberately deferred at the time).
• The recommendation's warning text is not regenerated after a default is created — see Chapter 7 §7.4. The real CashierAppsSettings/UserCashierSetting state is correct immediately after apply; only the already-generated warning strings from the earlier POST .../recommendation call remain stale "Phase 1" wording until the tenant regenerates a recommendation.
• No frontend messaging change was made or required — the existing warnings/errors separation in the onboarding recommendation and apply responses was already sufficient to render these as non-blocking notices; this phase's findings confirm that contract, they don't change it.

10.5 Rollback

Setting TenantOperationalDefaultsApplyBridgeSettings:Enabled=false instantly reverts the automatic operational-defaults step to a logged-and-ignored no-op — no code deploy, no migration, and no already-created Warehouse/CashAccount/BankAccount/SalesInvoiceTemplate row or CashierAppsSettings/UserCashierSetting value is touched. The de-gated reference-data seeders and the new SaaS tables/seeder are always-on and have no equivalent toggle — rolling those back would require a code revert, though the additive-only migration means no data loss risk either way.