Simple Object Designer Documentation
Index

Publishing Failures

This page provides detailed troubleshooting for publishing failures in Simple Object Designer, including an index of the specific error messages support sees most often.

Understanding Publishing Failures

Where Failures Occur

Publishing can fail at:

  1. Validation - SOD checks configuration
  2. Generation - Creating AL code
  3. Compilation - Compiling code
  4. Deployment - Installing in BC

Knowing which stage failed narrows the cause enormously. A validation error is something in your SOD configuration; a compilation error is in the generated AL; a deployment error is Business Central refusing to install the finished app.

Error Sources

Source Nature
SOD Validation Configuration issues
AL Compiler Code/syntax errors
BC Deployment Schema/runtime issues
Compiler service Server-side, maintained by Hougaard

Errors vs. Warnings

A failed publish usually produces a list containing both. Only entries tagged Error block publishing. Entries tagged Warning — most commonly "Field/Codeunit/Table '…' is marked for removal" — are informational notices that an object is deprecated in a future BC version. They never stop the app from compiling.

When a publish fails, find the line tagged Error and work on that one.

Three habits that prevent most failures

  • Always run SOD from the same company. Switching companies leads to symbol and cache related publish errors.
  • Keep symbols fresh. On the Setup page run Refresh Symbols and answer Yes to clearing the cache.
  • Stay on the latest SOD version, and remember that updating SOD does nothing until you publish again.

Quick Error Index

Error text Stage Go to
Query has no root element, cannot publish Validation Query and data query errors
An invalid argument was passed to a 'List' data type method Validation Feature field without a type
\ is not a valid anchor on page Validation Anchor errors
The Field MetaData Hgd does not exist / is not present Generation Field MetaData errors
The given key was not present in the dictionary Generation Known product defects
AL0132 / AL0118 — field not defined Compilation Deleted field still referenced
AL0161 — inaccessible due to protection level Compilation Protected objects
AL0433 — field is removed Compilation Business Central Updates
AL0185 / PTE0004 — missing permission set Compilation Permission set errors
AL1043 — runtime version not supported Compilation AL-Go / runtime version
The length for the type 'Text' must be positive Compilation Text&#[;0&#]; from a Lookup field
Unexpected Compiler Output Compilation Unexpected Compiler Output
500 – The request timed out Compilation Compiler timeouts
A package with publisher 'Microsoft', name 'Application' … could not be found Compilation Application package not found
using RegisterTableConnection or cmdlet New-NAVTableConnection Compilation CRM / CDS / Dataverse tables
A member of type QueryColumn … is already defined Compilation Duplicate query column
The EntitySetName '…' is already being used Compilation Duplicate EntitySetName
The app has dependencies missing Deployment Dependency failures
The application object … is defined in multiple apps Deployment Object defined in multiple apps
Error parsing version string Deployment Environments

Validation Failures

Common Validation Errors

Error Cause Fix
Missing required field Incomplete configuration Fill in required data
Duplicate name Two objects with same name Rename one
Invalid reference References non-existent object Fix reference
Query has no root element Query with no data items Add a root data item or delete the query
An invalid argument was passed to a 'List' data type method Feature field with no Type Set a Type on every feature field
\ is not a valid anchor on page Anchor no longer exists Re-select the anchor; verify features

Query and Data Query Errors

Several publish failures come from queries that were started and never finished. SOD validates every query on publish, whether or not you use it.

Query has no root element, cannot publish.

A query exists but has no root (top-level) data item. Open Expose Data > Data Queries, add a root data item — the first data item is the primary table — or delete the query if it is not needed.

Empty query with no elements at all. An empty Data Query blocks publishing. This happens easily by accident: autosave can persist a query you created but never populated, and testing the Data Query function can leave an empty Query category behind. Go to Data Queries, find the query with no elements, and either populate it or delete it.

A datalink filter on the top-level element can also trigger a publish error. Review it and remove it if it is not needed.

Note that refreshing symbols and updating SOD do not fix these — they are configuration problems and must be corrected in the query.

An invalid argument was passed to a 'List' data type method

Cause: a feature field was left without a Type — it shows as 0 in the Feature Fields list.

Fix: assign a valid Type to every feature field, then republish.

\ is not a valid anchor on page

Symptom: publishing (or Download source code) fails with an error such as No. is not a valid anchor on page. The message does not say which page or which placement is at fault.

Call stack, for searchability: the error is raised in codeunit 70310250 Build Extension Hgd, functions VerifyThanAnchorExist and ExportPageExtensions, triggered from the ExportExtension action on page 70310263 Object Designer Menu Hgd.

Cause: either a Feature in your solution contains an invalid anchor, or an invalid anchor was specified when placing a field on a page.

Resolution, in order:

  1. Go through your Features and run Verify Feature on each
  2. On the SOD Setup page run Refresh Symbols, answering Yes to clear the cache
  3. Go through all field placements and confirm the anchor still exists in the anchor lookup — re-select it from the lookup where needed

Note this error blocks Download source code as well as publishing, so it is not limited to the publish action.

If it persists: use Export App on the Setup page to produce the app JSON and send it to Hougaard support for analysis. That is the correct escalation — rebuilding the app in a new sandbox is not.

The Field MetaData Hgd does not exist

Error forms:

The Field MetaData Hgd does not exist. Identification fields and values: TableNo='<n>',No.='<n>'
'Field MetaData Hgd' is not present. Identifying fields and values: Table Number='<n>', No.='<n>'

The message may appear localized (for example in German or Spanish). The AL call stack points at Build Extension Hgd (codeunit 70310250), method ExportTableExtensions, or at Modern Build Extension's export of table extensions.

This error has three distinct causes; work through them in order.

1. Stale or incomplete symbol cache. The Field MetaData cache is missing entries the generator expects. This often follows a publish attempt that appeared to hang at an early stage (for example stuck on "Building Bridges") and never produced the .app.

  1. Open the SOD Setup page
  2. Refresh Symbols
  3. Answer Yes to clear the cache first
  4. Retry publishing

Also confirm you are always running SOD from the same company — switching companies causes exactly this class of error.

2. A FlowField filter pointing at a field number that does not exist. The TableNo and No. in the error identify the table and the missing field number the filter refers to (a filter referencing field 99999 when the correct field is 99998, for example). Note the table cited may be the related table, not the table where the FlowField is defined — the FlowField can live on a standard table like Vendor while its filter points at a field on a feature table.

This commonly appears after renumbering FlowFields, because FlowField settings do not follow a changed field number. Review the affected Field Settings — particularly FlowField Filters and related-field references — and correct them. See Field Settings.

3. A Lookup field pointing at a table or field that no longer exists. Typically after deleting fields from a table you created earlier. Review the Lookup fields in the affected objects and correct or remove any lookup referencing deleted metadata.

Compilation Failures

Common Compilation Errors

Error Likely Cause Solution
"Identifier not found" Bad field reference Fix reference
"Type mismatch" Incompatible types Check types
"Circular dependency" Object references Use Dual-App mode
AL0132 / AL0118 Deleted field still referenced Remove all references, refresh symbols
AL0161 Table or field protected by Microsoft Cannot be exposed; remove the usage
AL0433 Field removed by a BC upgrade Remove it from the API; see BC Updates
AL0185 / PTE0004 Permission set mismatch Send generated source to support
AL1043 Runtime version in app.json Update SOD
"The length for the type 'Text' must be positive" Lookup generated as Text[0] Delete and recreate the field

AL0132 and AL0118 deleted field still referenced

AL0132: 'Record "<Table>"' does not contain a definition for '<Field>'
AL0118: The name '"<Field>"' does not exist in the current context

The generated files named in the error still reference a field you deleted — typically src/API/<table>SOD.APIPage.al and src/PageExtensions/<Page>PageExt.al.

This is a compilation error, so Force Sync does not help. Force Sync addresses schema/data-loss issues, not code that references something that no longer exists.

Fix:

  1. Remove the field from every page placement
  2. Remove it from every report placement
  3. Remove it from every API endpoint
  4. Run Refresh Symbols with cache clearing — the cache may still contain the deleted field
  5. Publish again

In Dual-App mode, uninstall App 2 before republishing. In stubborn cases, uninstall the app, refresh symbols with cache clearing, and publish again.

The same error can also mean a field was removed or renamed in a source extension you depend on. If refreshing symbols does not clear it, confirm the field still exists on the source table; if it does not, exclude it from your API configuration.

AL0161: inaccessible due to its protection level

AL0161: '"Message Id"' is inaccessible due to its protection level
AL0161: 'Table <name>' is inaccessible due to its protection level

Microsoft has marked the field or table as protected or internal, so the generated app cannot touch it. This affects certain restricted standard tables — table 8889 "Sent Emails" is a known example — and tables belonging to other extensions that do not expose them.

This is a Microsoft platform restriction that SOD cannot override. The table cannot be exposed as an API. Deselecting the individual field is not enough when the whole table is off limits; remove the usage entirely.

AL0185 and PTE0004 permission set errors

Error AL0185: Query '<QueryName>' is missing
Error PTE0004: Table <ID> '<TableName>' is missing a matching permission set.

These appear during the compilation phase, in the generated Permissions/ file and in generated Features/<name>/<name>.Table.al files. PTE0004 means a generated table object has no matching entry in the extension's permission set; AL0185 means a generated query is missing from it.

These can affect several tables at once, and they can appear for a feature that published successfully many times before — so "it used to work" does not mean the configuration is intact.

Resolution: the cause is not deducible from the error text alone. Send diagnostics to support:

  • Use Download Source to produce a ZIP of the generated AL source and email it to support@hougaard.com, or
  • Send the generated .app file. Because .app attachments are commonly blocked by mail filtering, rename it to .txt before sending.

AL1043: runtime version not supported

AL1043 The runtime version '<version>' is not supported by the AL compiler.

Seen in AL-Go / CI-CD builds. It is caused by an incompatible runtime / application version combination in the generated app.json — a defect in older SOD versions.

Fix: update SOD to the latest version, which corrects the generated values. Do not hand-edit app.json in the repository; SOD regenerates it on every publish.

A related known issue: a referenced module built with runtime reference version 14.3 cannot be loaded by a compiler at version 14.0. Check for an updated SOD release rather than changing your own app.

The length for the type 'Text' must be positive

This blocks generation of the .app entirely — compilation fails and no app is produced.

Cause: a Lookup field was generated as Text[0] in the AL source instead of inheriting the length from the related table's field. It happens when the underlying field in the lookup's related table has changed, so the size did not populate.

The error refers to the AL type declaration — the number inside the brackets — not to stored data length. Deleting and re-adding text fields does not help if the offending line still has no valid length.

Fix: delete the affected Lookup field in SOD and recreate it. On recreation SOD re-populates the size from the related table, producing a valid declaration such as Text[100]. Manually typing a size is not reliable; recreating the field is.

Unexpected Compiler Output

The error appears as "Unexpected Compiler Output" (SOD may display it misspelled as "Unexcepted Compiler Output"). It occurs during compilation / .app generation, not during validation of your fields, so it usually does not indicate a problem with a specific field you created.

Resolution, in order:

  1. On the SOD Setup page run Refresh Symbols, answering Yes to clear the cache. Wait for it to complete (a few minutes), then publish again.
  2. If it persists, switch back to the Legacy Compiler using the compiler field on the Setup page, and publish again.
  3. Make sure you are on the latest SOD version — BC Admin Center > select environment > Apps > update Simple Object Designer.

500 Request Timed Out

Symptom: Unexpected Compiler Output 500, followed by an HTML body containing 500 - The request timed out. and "The web server failed to respond within the specified time."

This originates from the Business Central compiler service, not from SOD directly — the BC web server did not respond in the allowed window during compilation.

Common causes: a temporarily slow or overloaded environment; a large extension that takes longer to compile than the server allows; transient issues in the Microsoft-hosted compiler service (more common in SaaS).

Resolution, in order:

  1. Retry — it is often transient and succeeds a few minutes later
  2. Publish fewer changes at once — split large batches of modifications where possible
  3. Check the environment — on SaaS check the BC admin center for service issues; on-premises check CPU/memory on the BC server
  4. Restart the session — sign out of Business Central and back in for a fresh session
  5. Restart the environment — Admin Center > Session > restart. Use this when the error persists across days rather than being a one-off

If it still fails, support can investigate with the diagnostic IDs from the error dialog — see Capturing diagnostics.

A package with publisher 'Microsoft', name 'Application' … could not be found

A package with publisher 'Microsoft', name 'Application', and a version compatible with '26.0.0.0'
could not be found in the package cache folders: ...\.alpackages

The version matches the platform major version (26.0.0.0, 27.0.0.0, …) and the path points at a temporary .alpackages folder.

Root cause: a known Microsoft bug affecting symbol resolution for the Microsoft Application package. It is not simply stale symbols.

Resolution — the Alternative API Dependencies setting:

  1. Update SOD to 12.0.0.651 or later, which includes the setting
  2. Open the SOD Setup page. The Alternative API Dependencies field is hidden by default — use personalization to surface it
  3. Enter exactly: 88573c9d-8c3c-467d-807e-8476c43a03bf
  4. Refresh symbols and publish again

The value must be entered exactly. A typo here is the most common reason the fix appears not to work.

If it still fails, verify the symbols contain the base application:

  1. On the Setup page, Refresh Symbols, answering Yes to clear the cache
  2. Use Download source with Include Symbols in source download checked
  3. Inspect the downloaded .alpackages folder and confirm it contains the base application file for the BC distribution in use. If it is absent, symbols did not download completely.

RegisterTableConnection and New-NAVTableConnection

using RegisterTableConnection or cmdlet New-NAVTableConnection before it can be used.

Cause: the extension references a CRM / CDS / Dataverse table — any table, field or page whose name contains "CRM", "CDS" or "DataVerse". These require a registered table connection and cannot be used directly by a generated SOD extension.

Fix: find and remove the usage, then republish.

Where it hides: the reference can come from anywhere in the extension, not only the object you were editing — a separately configured API endpoint exposing a CRM/CDS/Dataverse table is a frequent culprit. Check features, fields, lookups and API endpoints alike.

A member of type QueryColumn … is already defined

A member of type QueryColumn with name '<fieldname>' is already defined in Query '<QueryName>'
by the extension '<ExtensionName> (<version>)'

Cause 1: the same field name is included twice in the query columns — common when joining two tables that share a field name. Include the field only once.

Cause 2: stale symbols. If the columns are genuinely correct and the error still appears, Refresh Symbols clears it.

The EntitySetName '…' is already being used

The EntitySetName 'sales_Cr_Memo_Headers' is already being used.
The EntityName and EntityNames property values must be unique.

An API with that EntitySetName already exists — either elsewhere in the same app you built with SOD, or in another app.

Ask first: is more than one SOD-created app installed? A duplicate commonly arises when a second SOD app defines the same EntitySetName. Note the conflict is about the app you created with SOD, not SOD itself.

Apps belonging to a different publisher and group should not conflict on EntitySetName, so an unrelated third-party extension is not the source.

Fix: locate the duplicate API definitions and remove or rename them so every EntitySetName is unique.

Names that break compilation

Two naming rules cause otherwise-baffling publish errors:

  • A name must not start with a number. A field or calculated field named 2ndUoM… verifies fine in the designer but fails package validation with AL0104: Syntax error, ')' expected, AL0104: Syntax error, '{' expected and AL0124: The property '…' cannot be used in this context.
  • Non-ASCII characters in names cause errors or warnings. National characters such as Ø, Æ, Å and accented letters — for example the Ø in "Leverandør PowerBI" — should be replaced with plain ASCII (O/OE, AE, A). This is often the underlying cause when a publish error names an element and the message makes no sense.

When a publish error names a line in a generated file, inspecting the identifiers at that line for these two problems is a fast first check.

Reports and the compiler choice

There are two compilers, and they behave differently: the Legacy Compiler and the Microsoft compiler. They produce different errors, so confirm which one was actually in use before reporting a problem — errors are frequently misattributed.

Report generation is only supported by the Microsoft compiler. The Legacy Compiler cannot compile a report. This is why report creation and printing — for instance generating an order acknowledgement from a sales order — is not currently supported from the Document or Data Table features. The capability is planned with no confirmed ETA and is expected to align with the BC27 release; enabling the Microsoft compiler in SOD was in part groundwork for it.

Deployment Failures

Schema Sync Failures

When BC can't sync the schema:

Error Cause Solution
"Cannot sync" Data loss would occur Use Force Sync if appropriate
"Table locked" Table in use Wait or retry later
"Field type change" Incompatible change Force Sync or restructure

Dependency Failures

Error Cause Solution
"Dependency not found" Missing required extension Install dependency
"Version mismatch" Wrong dependency version Update dependency
"Circular dependency" Can't resolve order Use Dual-App

The app has dependencies missing. Please ensure that the dependency is available in AppSource or is installed as another PTE and slotted in the correct version.

The generated app depends on Microsoft or third-party extensions that exist in the source environment but are missing — or installed at a different version — in the target. The error lists the app name, version and app ID that must be present before your customization can install.

This is the classic cause of "sandbox works, production fails": the sandbox has extensions the production environment lacks. See Environments.

Inherited (transitive) dependencies. Sometimes the missing extension is one you have never used — a localization app for a country you do not operate in, for instance. The rule is: if one of your app's dependencies itself depends on extension X, your app depends on X too. This does not come from anything in your own customization; it comes from the chain of extensions your app references. The dependency list inside the .app file confirms it, and support can review an uploaded .app to identify which upstream dependency introduced it.

The application object … is defined in multiple apps

The application object of type '<type>' with the ID '<number>' is defined in multiple apps.

Cause 1 — object number collision. Another installed extension uses the same object number. Diagnose with the ToolBox app's Object Inspector to see what holds that number.

Cause 2 — Dual-App mode. Object numbers get shuffled between App 1 and App 2 on republish, so the same object can end up in both. Uninstall App 2, then republish. See Dual-App Deployment.

Permission Failures

Error Cause Solution
"Access denied" No publish permission Get proper permissions
"Not authorized" Account issues Check credentials

Allow HttpClient Requests is off

Symptom: publishing fails in one environment (typically a sandbox) while exactly the same configuration publishes fine in another (typically production).

Cause: the Allow HttpClient Requests toggle is turned off for the Simple Object Designer extension in that environment.

Fix:

  1. Open Extension Management in Business Central
  2. Locate the Simple Object Designer extension
  3. Turn Allow HttpClient Requests on
  4. Retry publishing

This setting differs per environment and is not reliably carried over when a sandbox is copied from production — which is why symbols, extensions and configuration can all match while publishing still fails in one place.

The publish screen freezes on BC27

Symptom: on the latest BC27 version, publishing appears to hang on the publishing screen, sometimes requiring the browser to be closed.

This is a Microsoft bug in that BC27 version, not an SOD or app problem, and it does not occur on BC26.5.

Important: despite the frozen screen, publishing still completes successfully. Confirm by opening Extension Management — the app version number will have incremented.

A workaround is included in the SOD version submitted to AppSource after this issue; update to the latest version to stop the freeze.

Publishing fails right after a new BC major version

Publishing errors that appear immediately after a new Business Central major version is released may come from SOD's compiler service, a server-side service maintained by Hougaard. Each new BC major version requires an update to that service, deployed by Hougaard rather than by you.

Local troubleshooting — initializing a new app, reimporting definitions, clearing caches, refreshing symbols — will not help, because the fix is server-side. Once the service update is deployed, simply retry publishing.

If you hit a publish error immediately after a BC version upgrade, contact Hougaard support to confirm whether a compiler service update is pending instead of repeatedly attempting local fixes.

Failures caused by removed or relocated Microsoft fields

When Microsoft removes a field, or moves it to a different app, in a new BC version, an SOD extension that references it fails compatibility. Known examples: Coupled to Dataverse on Job Task (removed in BC 28 when Field Service moved to its own app), Coupled to CRM, Service Commitment Option on Item (BC 26), and IRS 1099 Code on Vendor (moved to the IRS Forms App).

The error may look like it blames SOD because the generated object file name contains "SOD", but the fix is made inside SOD's configuration:

  1. Identify the removed or relocated field from the compatibility email or error text
  2. Ensure you are on the latest SOD version
  3. Go to Expose Data > Expose data as web service APIs, open the affected endpoint, and exclude the field from the field list
  4. Remove any other use of the field (placement, transfer, reference)
  5. Republish, then retry the BC upgrade
  6. If the field still exists in a new location, re-create what you had using the new location

The error persists until the field is excluded from every API that references it. Full detail in Business Central Updates and Compatibility.

Known Product Defects

The given key was not present in the dictionary

Symptom: publishing fails with The given key was not present in the dictionary. The AL call stack references SOD's own codeunits — Build Queries Hgd (ExportQueryDataLink, ExportQueryElement, GetQuery, ExportQueries), called from Build Extension Hgd.CreateExtensionEx during ExportExtension.

Cause: a defect in SOD relating to query data links and element export.

Fix: update SOD to 12.0.0.564 or later from AppSource and publish again. If updating does not resolve it, capture the Share Details and send them to support.

Using Force Sync

When to Use

Force Sync for:

  • Removing fields with data
  • Type changes
  • Major restructuring

Force Sync does not fix compilation errors. If the error names a missing field definition or a syntax problem, Force Sync will not change the outcome.

How to Use

  1. Backup affected data
  2. Set Publish Update Mode to Force Sync
  3. Publish
  4. Set back to Synchronize
  5. Verify results

Risks

Force Sync may:

  • Delete data
  • Cause irreversible changes
  • Impact users

See Force Mode for details.

Diagnosing a Failure

Get Source Code from selected error

When a publish produces compilation errors, select the error in the list and use Get Source Code from selected error. It shows the generated source location where the offending identifier is used, which usually identifies the configuration item that introduced it. The action name may be localized.

Download Source

Download Source on the Setup page produces a ZIP archive of the generated AL code. Use it to:

  • Open the AL file named in an error and read the exact generated line
  • Send the archive to support

Check Include Symbols in source download when you also need to verify what symbols were downloaded.

Capturing diagnostics for support

Depending on the failure, support may ask for one of:

Artifact How to produce it When
Generated AL source Download Source on the Setup page Compilation and package validation errors
App definition JSON Export App on the Setup page Validation errors such as invalid anchors
The .app file Download after publish PTE0004, dependency questions
Share Details The error dialog's Share Details option Runtime errors during export

Share Details captures the error message, Internal session ID, Application Insights session ID, Client activity id, timestamp, User telemetry id and the full AL call stack.

Email artifacts to support@hougaard.com — the support forum does not accept source attachments. If a .app or .zip attachment is blocked by mail filtering, rename it to .txt first.

Troubleshooting Steps

Step 1: Read the Error

Carefully read:

  • Error message text, and whether it is tagged Error or Warning
  • Which stage failed (validation, generation, compilation, deployment)
  • Which object and, where given, which file and line

Step 2: Identify the Cause

Common causes:

  • Incomplete configuration (empty queries, untyped feature fields, missing anchors)
  • References to deleted or removed fields
  • Stale symbols
  • Missing dependencies in the target environment
  • Conflicts with existing objects
  • Permission issues

Step 3: Fix the Issue

Based on cause:

  • Correct configuration
  • Remove stale references
  • Refresh symbols with cache clearing
  • Resolve conflicts
  • Get proper permissions

Step 4: Retry

After fixing:

  1. Try publishing again
  2. Check for new errors
  3. Repeat if needed

Step 5: Verify Success

After successful publish:

  1. Check deployment status
  2. Test the changes
  3. Confirm everything works

Preventing Publishing Failures

Before Publishing

  1. Review all changes
  2. Check for obvious issues
  3. Verify references exist
  4. Delete any queries or features you started but did not finish
  5. Test in sandbox first

Regular Practices

  • Keep symbols updated
  • Always work from the same company
  • Update SOD before a BC version update, and republish afterwards
  • Make incremental changes
  • Test frequently
  • Document changes

When to Seek Help

Self-Help First

Try:

  • Reading this documentation
  • Checking whether the message is an Error or a Warning
  • Refreshing symbols with cache clearing
  • Updating SOD to the latest version and republishing

Contact Support When

  • Error messages are unclear
  • You've tried all suggested fixes
  • Issue persists after multiple attempts
  • The error is PTE0004 or AL0185 on permission sets
  • Need guidance on approach

Include the appropriate diagnostic artifact — see Capturing diagnostics for support.