App Bundles

An App Bundle is the top-level container in Aptean Mesh that groups mobile pages, workflows, service registry entries, and dependencies into a single deployable unit. Each bundle represents a complete mobile application configuration stored in the Mobile App Bundle 220FDW table.

Bundle Fields

The table below lists every field on the Mobile App Bundle 220FDW record, taken directly from the AL source.

Field	Type	Editable	Description
ID	Guid	No (auto-generated)	Unique identifier, created automatically on insert via CreateGuid().
Code	Code[20]	Yes (when unlocked)	Short human-readable identifier for the bundle (for example, DEMO, WAREHOUSE). Must not be blank.
Description	Text[50]	Yes (when unlocked)	A short description of the bundle's purpose.
Version	Integer	No	Bundle version number. Initialized to 1, minimum value 1.
Publisher	Text[30]	No	The publisher of the bundle. Set by the system.
Locked	Boolean	No	When true, the bundle cannot be modified or deleted. Set automatically for system bundles.
Status	Enum AppBundleStatus220FDW	Yes	Lifecycle status -- see the next section.
Root Page ID	Code[50]	Yes (when unlocked)	The page ID loaded first when the mobile app connects. Must reference a valid MobilePage220FDW record within the same bundle.
Mobile Page Count	Integer	No (FlowField)	Computed count of mobile pages belonging to the bundle.
Workflow Count	Integer	No (FlowField)	Computed count of workflows belonging to the bundle.
Service Setup Count	Integer	No (FlowField)	Computed count of service registry entries belonging to the bundle.
Dependency Count	Integer	No (FlowField)	Computed count of app dependencies declared by the bundle.
Min Client Version	Integer	No	Minimum mobile client VERSION_CODE required to run the bundle. Leave at 0 to allow all client versions.

Keys

Key	Fields	Notes
PK	ID	Clustered primary key.
PublisherVersion	Publisher, Version	Secondary key for publisher-based lookups.
UniqueBundle	Code, Publisher, Version	Unique constraint -- no two bundles can share the same code, publisher, and version.

Bundle Lifecycle

The AppBundleStatus220FDW enum defines four statuses:

Value	Enum Name	Caption	Description
0	Dev	Development	Active development. Bundle is fully editable.
1	Test	Test	Testing phase. Bundle is still editable.
2	Production	Production	Live bundle served to all users. Cannot be modified.
3	Archive	Archive	Retired. No longer served to any user.

The enum is not extensible -- these are the only valid statuses.

Status Transitions

Bundle Lifecycle

Dev

──▶

Test

──▶

Production

──▶

Archive

• Dev to Test -- marks the bundle as ready for QA validation.
• Test to Production -- promotes the bundle to live. The system enforces that only one Production bundle can exist at a time. If another Production bundle already exists, Business Central raises an error: A Production bundle already exists (<Code>). You must change its status before activating this one.
• Production to Archive -- retires the bundle.

Edit Protection

Two mechanisms prevent modifications:

1. Status = Production -- any field change triggers: Production bundles cannot be modified. Change status to Dev or Test first.
2. Locked = true -- any field change triggers: Locked system bundles cannot be modified or deleted. Copy the bundle to customize.

These checks also apply to child records (pages, services, workflows, dependencies, user assignments). Child tables call CheckNotLockedById before insert, modify, or delete operations.

Creating a New Bundle

1. Search for Mobile App Bundles in Business Central.
2. Click New to create a bundle.
3. Fill in:
   • Code -- a short identifier such as WHS or PICKING.
   • Description -- for example, Warehouse Picking App.
4. The ID is generated automatically, Version defaults to 1, and Status defaults to Dev.
5. Set the Root Page ID to the page that should load first (see below).
6. Add mobile pages, service registry entries, and workflows as needed.

Setting the Root Page ID

The Root Page ID determines which page the mobile client renders first after connecting. It must reference a valid MobilePage220FDW record within the same bundle (enforced by table relation).

Common patterns:

• Navigation menu page -- a page with buttons linking to different workflows (for example, a hub page with links to Receiving, Picking, and Put-Away).
• Single-purpose workflow page -- for focused apps that do one task (for example, a cycle-count app that opens directly to a scan screen).

If the Root Page ID is empty when the mobile client calls GetPageFlow, the system raises: Root Page ID is not configured in the App Bundle. Please set a Root Page ID in the Mobile App Bundle setup.

Setting a Minimum Client Version

The Min Client Version field lets you enforce that users run a sufficiently recent version of the mobile app. When the client calls GetPageFlow, the system compares the client's reported VERSION_CODE against this value. If the client version is lower, the system raises: Your app is outdated. Please update to the latest version from the Play Store.

Leave this field at 0 to skip the version check entirely.

Bundle Resolution at Runtime

When a mobile client connects, the system determines which bundle to serve using this logic (implemented in GetActiveBundle):

1. User assignment check -- look up the current user in Mobile User Assignment 220FDW. If found, and the assigned bundle has status Dev or Test, serve that bundle.
2. Production fallback -- if no user assignment exists (or the assigned bundle is not Dev/Test), serve the single Production bundle.
3. Error -- if neither lookup succeeds, raise No active Mobile App Bundle found.

This means developers and testers can work with Dev/Test bundles without affecting other users who continue to receive the Production bundle.

User Assignments

For Dev and Test bundles, use User Assignments to control access:

1. From the App Bundle card, navigate to User Assignments.
2. Add the Business Central user IDs that should see this bundle.
3. Assigned users receive this bundle instead of the Production bundle.

This allows:

• Developers to iterate on pages and services without disrupting production users.
• QA teams to validate a Test bundle before promotion.

Copy Bundle

The Copy Bundle action creates a duplicate of the current bundle with Dev status. The copy includes:

• All mobile pages and their JSON definitions
• All service registry entries
• All workflows

This is the recommended workflow for making changes to a Production or locked bundle -- copy it, make edits in the Dev copy, test, and then promote the copy to Production.

Deleting a Bundle

Deleting a bundle also deletes all child records:

• Mobile pages (MobilePage220FDW)
• Workflows (Mobile Workflow 220FDW)
• Service registry entries (Mobile Service Registry 220FDW)
• App dependencies (Mobile App Dependency 220FDW)
• User assignments (Mobile User Assignment 220FDW)

A locked or Production bundle cannot be deleted. Change the status first, or archive it instead.

Multi-Bundle Scenarios

Because only one Production bundle can be active at a time, multi-bundle workflows rely on user assignments:

• Parallel development -- multiple teams each create their own Dev bundle and assign their members. Each team sees only their bundle.
• Staged rollout -- promote a new bundle to Test, assign QA users, and keep the current Production bundle live for everyone else. Once validated, promote the new bundle to Production (the old one must be archived or moved to a different status first).
• Publisher/version segmentation -- the unique key on Code + Publisher + Version allows multiple versions of the same bundle code from different publishers. This supports extension-based bundle delivery where different apps ship their own bundles.

App Dependencies

Bundles can declare dependencies on other Business Central extensions via the Mobile App Dependencies sub-page. This ensures that required extensions are installed on the tenant before the bundle is activated. The dependency count is visible on the bundle card as the Dependency Count FlowField.