9. Onboarding and Settings Entitlement Behavior
Full onboarding mechanics are documented in Business Onboarding & Smart Configuration. This chapter records only the live-verified entitlement-filtering outcome specific to the four Shumoul packages.
9.1 Live-verified settings-group filtering, per package
For each package, a test tenant registered, verified, logged in, submitted onboarding answers, and
generated a recommendation. OnboardingRecommendationService removes any settings group the survey
would otherwise recommend if the tenant's active subscription does not entitle it — confirmed exactly
as designed:
| Package | Settings groups in the final patch | Groups removed with a subscription warning |
|---|---|---|
| Shumoul Starter | ProductSettings, CashierAppsSettings, DiscountSettings, TaxSettings | LoyaltySettings, CostCenterSettings, FinancialSettings, NotificationSettings |
| Shumoul POS | ProductSettings, CashierAppsSettings, DiscountSettings, TaxSettings, NotificationSettings | LoyaltySettings, CostCenterSettings, FinancialSettings |
| Shumoul Finance Starter | CostCenterSettings, FinancialSettings, TaxSettings | CashierAppsSettings, ProductSettings |
| Shumoul Finance Advanced | CostCenterSettings, FinancialSettings, ProjectSettings, TaxSettings | CashierAppsSettings, ProductSettings |
Every removal produced the expected Onboarding.Validation.SettingsGroupNotAllowedBySubscription
warning — the patch is never silently narrowed without explanation.
9.2 First-login survey behavior
All four packages produce an identical isRequired: true, status: "NotStarted" on first login — the
survey itself is package-agnostic (the same questions for every tenant); only the recommendation
step differs by package entitlement. No package skips or shortcuts the survey.
9.3 Apply
POST onboarding/apply returned the expected 501 ("the onboarding apply bridge is not configured")
for all four packages during this task's dev verification — the bridge is disabled by default in every
environment (see the Tenant Signup guide, Chapter 10),
and this task did not re-enable it (per its own instruction not to run Apply unless necessary/safe —
the entitlement-filtering behavior above was already fully observable via the recommendation step
alone).
