Skip to main content
Version: Latest

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:

PackageSettings groups in the final patchGroups removed with a subscription warning
Shumoul StarterProductSettings, CashierAppsSettings, DiscountSettings, TaxSettingsLoyaltySettings, CostCenterSettings, FinancialSettings, NotificationSettings
Shumoul POSProductSettings, CashierAppsSettings, DiscountSettings, TaxSettings, NotificationSettingsLoyaltySettings, CostCenterSettings, FinancialSettings
Shumoul Finance StarterCostCenterSettings, FinancialSettings, TaxSettingsCashierAppsSettings, ProductSettings
Shumoul Finance AdvancedCostCenterSettings, FinancialSettings, ProjectSettings, TaxSettingsCashierAppsSettings, 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).