Simple Object Designer Documentation
Index

Limitations — What SOD Can and Cannot Do

Simple Object Designer is deliberately "simple". It covers a wide range of customizations without code, but there is a boundary, and knowing where it runs saves a great deal of time. This page collects the limitations that come up most often in support, and points to the right alternative for each.

The Rule of Thumb

SOD is built for additive customization: adding fields, placing them on pages and reports, adding rules, and building new tables and features from templates.

If a requirement is more than adding fields and placing them, and especially if it requires reacting to when something happens or writing into data Business Central already manages, it is likely outside SOD's scope and needs a Business Central developer. See Graduating from SOD — you can always download the generated AL source and continue in code.

Page and UI Limitations

Fields cannot be hidden

SOD cannot hide fields or make them invisible on a page. There is no field visibility control in the app. Hiding standard fields must be done another way — for example through page personalization, profiles, or permissions.

Action buttons cannot be created or moved

SOD does not create new action buttons, and it cannot place an existing action button on a different page.

The reason is that an action button is code that executes in a specific context; that code cannot simply be invoked from somewhere else. Taking the "Close" button from a document card page and surfacing it on the corresponding list page, so records can be actioned from the list, is not possible.

Field labels cannot be styled or colour-coded

You cannot change the colour of a field label (caption), and you cannot add coloured stars or icons next to fields. This is a Business Central platform restriction, not an SOD gap — Microsoft does not expose caption styling.

A common underlying goal is to signal which department is responsible for filling in each field on a card. There is no "simple" way to do that. Item Templates can pre-populate fields, but they provide no per-department visual cue for fields that must be entered manually.

Conditional font styling through a calculated field (StyleExpr) is likewise not available — see Calculated Fields Overview.

Values in standard lookups cannot be restricted

SOD cannot add a filter that limits which values are selectable in fields on sales and purchase order lines — for example restricting the items available in Sales Line field 6 "No.".

The Advanced Cloud Security App provides this capability. See https://hougaard.com/security.

Data and Logic Limitations

Existing fields cannot be auto-populated

SOD cannot automatically write values into existing fields. Wanting a standard field such as "Requested Delivery Date" (field 5790) to be filled in automatically from the order date, so users do not have to type it, is not supported.

The reason is safety: it is very hard for SOD to determine when it is safe to write into a field that Business Central itself manages, and writing at the wrong moment can produce incorrect data.

Nothing can react to posting

SOD cannot change a field value in response to a document being posted. There is no mechanism to hook posting events.

Alternative for capturing posting time: posted records carry the SystemCreatedAt field, which holds the moment the posted record was created — in other words, the time of posting. Use that instead of trying to stamp a custom date field during posting.

Dimensions

Dimension values are not stored on the document record. They live in a separate table, linked through the Dimension Set ID.

Consequences:

  • Standard dimensions can be filtered on as usual.
  • Extracting a specific dimension value from a record and writing it into another field is not possible with SOD. It requires a developer.
  • Shortcut dimension fields cannot be added to a page or table by SOD. This needs a fair amount of extra code to work correctly. A custom field can achieve a similar result, but it must be added individually to each relevant table and page — a manual alternative, not SOD support for shortcut dimensions.
  • In Mandatory Field rules, only Global Dimension 1, Global Dimension 2 and Dimension Set ID are available as condition fields. Non-global dimensions cannot be referenced, because of how dimensions are constructed in Business Central. There is currently no workaround inside SOD; this may be addressed in a future release.

A specific case that comes up regularly: when running Create Sales Order/Invoice from a Project card, the "Project No." transfers to the resulting sales header but the "Project - code" shortcut dimension does not. Populating it automatically is not possible with SOD configuration and requires a developer to customize the create-order function. Because "Project - code" is a shortcut dimension, a developer must set it through standard dimension logic (for example ValidateShortcutDimCode) rather than assigning the field directly, so that the dimension set entry is updated correctly.

Calculations on fields

SOD has no built-in way to write a computed value into a stored field — a line total from quantity × unit price, for example. FlowFields can aggregate existing stored fields, and calculated fields can display an expression, but neither stores a computed line value. See FlowFields and Calculated Fields Overview.

Archive tables and "latest version" queries

Business Central and AL provide no easy way to run a "distinct" query over archive tables, and archive tables carry no built-in "last entry"/latest-version marker.

As a result there is no simple way to build, say, a field or table on a Customer Card listing unique archived quotes — one row per quote rather than one per version — with number, reference, date, amount and a link to open the newest archived version. This is a Business Central data-model constraint rather than an SOD-specific gap.

File and Attachment Limitations

No file upload / attachment functionality

SOD cannot add the ability to upload and attach related files to individual records — for instance attaching documents to warehouse receipts.

Recommended alternative: the SharePoint Connector app, a separate product from hougaard.com. It is the go-to solution for attachment and document-management requirements that SOD cannot cover.

Note the distinction: a Blob field can store and display a picture on a card page (see Field Types), but that is a single image on the record, not general document attachment.

Item Attachment "Links" are stored in the Business Central table named Record Link.

  • Reading, updating or exposing Record Link data through an API is not simple and requires an AL developer.
  • The Record Link table uses a RecordID field, and RecordID-type fields are not API-friendly, which is precisely why exposing them is difficult.

For improved attachment and document handling generally, use the SharePoint Connector app.

API Limitations

SOD exposes; it does not consume

This is the most common misunderstanding about SOD's API features.

  • SOD can only expose Business Central data and business logic as APIs, for an external system to consume.
  • SOD cannot call, consume, or interact with external or third-party APIs. The direction is strictly outbound.

Any scenario in which Business Central must pull data from an outside system — retrieving shipment notifications, tracking numbers, or shipped quantities from a drop-ship provider, for example — needs development outside SOD.

Building such an integration means endpoint mapping, authentication, scheduling and error handling. That work belongs to a Business Central partner or developer with API integration experience; SOD covers only the exposure side on the BC end (inventory, pricing, sales order data, and so on).

If your regular BC partner is not comfortable taking on that integration, Hougaard's affiliated company EFOQUS (based in Canada, also serving US customers) can perform this type of work — contact Mark Buchman at EFOQUS. Proceed only if your existing partner is agreeable, to avoid a conflict.

Reports

Adding a field to a report is simple only when the value is already part of the report's dataset or layout. Data stored in a table that is not part of the report's data items cannot be added through SOD's simple approach.

Example: serial numbers live in item tracking entries, a separate table from the report's data items. Pulling them into a report is therefore not a simple task and requires a developer. See Add Fields to Reports for what is possible, including using a FlowField on a data-item table to bring a value into range.

New Tables and Larger Requirements

SOD's Features do create new tables from templates, with pages and basic logic. But requirements that need bespoke table structures, custom relationships, or business logic beyond what the templates and functions offer are outside the scope of "Simple" and require a BC developer.

When You Need a Developer

Reach for a developer when the requirement involves:

  • Reacting to events (posting, releasing, approving)
  • Writing into fields Business Central itself manages
  • Extracting or assigning dimension values
  • Consuming an external API
  • Adding data from a table that is not part of a report's dataset
  • Adding action buttons or moving existing ones
  • Anything requiring conditional formatting or visual styling
  • Lookup columns on tables that define no lookup field group

You are never locked in: the AL source SOD generates can be downloaded and taken over by a developer at any time. See Graduating from SOD.