Edition, hosting, and customization strategy for a 60-user prospect
Contoso Robotics is evaluating Business Central for 60 full users. Finance needs general ledger, sales, purchasing, inventory and projects; operations needs production orders with routings and capacity planning; the service team needs service orders, contracts and item tracking. The IT director insists on data residency in Germany, already runs an on-premises SQL Server, and wants to avoid a Premium subscription because "we only use a few extra features." He also proposes that the partner copy the base Customer and Item tables into the 50100 range, delete unused fields, and shorten a few field lengths "to simplify the model." Go-live is in five months and there is no internal AL developer.
1. Which edition does Contoso need, and which licensing facts drive that conclusion?
Read the worked answer
Premium. The deciding factor is not user count but which functional areas are touched:
- Manufacturing (production orders, routings, capacity planning) and Service Management (service orders, contracts) are Premium-scope functionality.
- Essentials would cover the finance, sales, purchasing, inventory, warehouse and project requirements, but not the operations or service requirements above.
- "Only a few extra features" is the wrong frame: the extra features are two entire application areas that the business plan depends on. Dropping them changes the project scope, not the license SKU.
Reasoning to apply on the exam: identify the modules first, then map to edition. Also point out that not every human needs a full user - people who only read data or approve occasionally may qualify for a cheaper named user type, which can reduce the 60-full-user count. That is a commercial recommendation, not a substitute for the edition decision.
2. Compare cloud, on-premises, and a hybrid split for this customer, and recommend one.
Read the worked answer
Recommendation: public cloud in a German (EU) region, unless a specific regulatory rule forbids it.
- Data residency: the cloud service is offered from datacenters in Germany, so "data must stay in Germany" is satisfied without on-premises hardware. Residency is a location question, not a hosting-model question.
- On-premises gives full control of the database and update timing, but the customer owns the upgrade treadmill: every release must be tested and applied by them, and they currently have no AL developer. With a five-month go-live this is the largest hidden cost.
- Hybrid (cloud plus on-prem components, e.g. an on-prem SQL reporting replica or a gateway to local systems) is justified only when a specific workload cannot move - for example a latency-sensitive shop-floor system. It adds operational surface area, so require a named requirement before choosing it.
- Automatic updates in the cloud are a feature, not a risk, provided the extension is written cleanly and validated in a sandbox before each update window.
The judgment: match the constraint to the model. "German data" points to a region, not to on-premises. "We have SQL Server" is an asset-sunk-cost argument, not a requirement.
3. Evaluate the IT director's plan to copy base tables, delete unused fields, and change field lengths.
Read the worked answer
The plan should be rejected. Each element fails for a different reason:
- Copying base tables into 50100 creates a parallel data model. Customer, Item, and every document that references them now exist twice. Posting, dimension handling, and reporting will read one copy while users edit the other. You also inherit responsibility for every base behavior you copied.
- Deleting fields from a copied table silently removes data that base logic assumes exists; in the real base table it is simply not permitted in a per-tenant extension.
- Changing field lengths on base fields is not possible through extension objects. Where a longer value is genuinely needed, add a new field beside the standard one and keep the standard field for compatibility.
- Upgrades break. Copied base objects are not upgraded with the base application, so each release becomes a manual merge. This is exactly the maintenance burden an extension model exists to avoid.
What to do instead: a per-tenant extension with table extensions and page extensions - hide unused fields with Visible = false on a page extension, add new fields with tableextension, and use events for changed behavior. Explain to the customer that "simplify the model" is achieved in the UI layer, not by forking the database.