[FS] Prevent duplicate Field Service customer assets during item synchronization

[tomasevicst]

What & why

Business Central and Field Service could both create a Customer Asset for the same item, resulting in duplicates when a Work Order was completed.

This change keeps Business Central as the source for Customer Asset creation by:

• Setting Convert to Customer Asset to No for Products synchronized from BC Items.
• Adding the rule to the default Item-Product mapping.
• Removing the Product flag as a filter for Service Item synchronization.
• Adding tests for runtime enforcement and mapping configuration.

Linked work

Fixes AB#649195

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Risk & compatibility

Risk is low and limited to coupled Field Service Products. Their Convert to Customer Asset value is overwritten to No during Item synchronization, preventing native Field Service asset creation.

Uncoupled Field Service Products are unaffected. No schema or public API changes are introduced. Existing configurations are covered by runtime enforcement, while reset or newly created mappings receive the constant outbound mapping.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The removed IgnoreServiceItem* tests, and the new ItemSynchronizationDisablesCustomerAssetConversion test, both call the helper procedure directly rather than exercising the actual dispatch path. Critically, the new 'Item-CRM Product' case added to OnBeforeTransferFieldData (which does DestinationRecordRef.SetTable(CRMProduct) / DisableCustomerAssetConversion(...) / DestinationRecordRef.GetTable(CRMProduct)) is never exercised by any test — no test drives an Item-to-CRMProduct transfer through the RecordRef dispatch to confirm the case is reached and the record is written back correctly. Add an integration-style test that triggers the Item-CRM Product transfer path (e.g. via the subscriber's OnBeforeTransferFieldData or a full sync call) and asserts the resulting CRM Product has ConvertToCustomerAsset = false.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.38.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Upgrade}$

The public test-library procedure IgnoreServiceItemsByConvertToCustomerAssetFlag is newly marked [Obsolete(...,'30.0')], but its body was simultaneously replaced with a no-op instead of continuing to delegate to the prior logic. Any dependent app or test still calling this procedure during the deprecation window (before 30.0 removal) will silently stop having IgnoreRecord evaluated/set, changing observable runtime behavior while the symbol still compiles. Staged-obsoletion guidance expects the procedure to keep working during the deprecation window and only become an empty/removed stub at or after the tagged removal version.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

    procedure IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef: RecordRef; var IgnoreRecord: Boolean)
    var
        FSIntTableSubscriber: Codeunit "FS Int. Table Subscriber";
    begin
        FSIntTableSubscriber.IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef, IgnoreRecord);
    end;

Knowledge:

• microsoft/knowledge/upgrade/obsolete-pending-to-removed-staging.md
• microsoft/knowledge/breaking-changes/deprecate-public-members-with-the-obsolete-lifecycle.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.39.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

The public procedure IgnoreServiceItemsByConvertToCustomerAssetFlag on the FS Integration Test Library codeunit was kept and marked [Obsolete(...,'30.0')], but its implementation was emptied instead of preserved. Emptying the body changes the procedure's observable behavior (IgnoreRecord is now always left unchanged) immediately for any remaining caller, rather than preserving prior behavior through the deprecation window until the tag's removal version. Prefer keeping the forwarding call to FSIntTableSubscriber.IgnoreServiceItemsByConvertToCustomerAssetFlag until the obsolete procedure is actually removed.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

    procedure IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef: RecordRef; var IgnoreRecord: Boolean)
    var
        FSIntTableSubscriber: Codeunit "FS Int. Table Subscriber";
    begin
        FSIntTableSubscriber.IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef, IgnoreRecord);
    end;

Knowledge:

• microsoft/knowledge/breaking-changes/deprecate-public-members-with-the-obsolete-lifecycle.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.40.6}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Upgrade}$

FS Integration Test Library.IgnoreServiceItemsByConvertToCustomerAssetFlag is marked [Obsolete] (pending, target version '30.0') but its body was stripped to a no-op instead of continuing to forward to FS Int. Table Subscriber.IgnoreServiceItemsByConvertToCustomerAssetFlag (which still has its full working implementation, also marked Obsolete-pending but not removed). During the obsolete-pending window a symbol must keep its previous observable behavior so existing callers are not silently broken before their deprecation window elapses. Any remaining caller of the test-library helper now always leaves IgnoreRecord unchanged instead of getting the real computed result, which is a silent behavioral regression, not just a documentation change.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

    procedure IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef: RecordRef; var IgnoreRecord: Boolean)
    var
        FSIntTableSubscriber: Codeunit "FS Int. Table Subscriber";
    begin
        FSIntTableSubscriber.IgnoreServiceItemsByConvertToCustomerAssetFlag(SourceRecordRef, IgnoreRecord);
    end;

Knowledge:

• microsoft/knowledge/upgrade/obsolete-pending-to-removed-staging.md
• microsoft/knowledge/breaking-changes/deprecate-public-members-with-the-obsolete-lifecycle.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

In the new 'Item-CRM Product' case of OnAfterTransferRecordFields, DisableCustomerAssetConversion unconditionally reads CRMProduct.ConvertToCustomerAsset, but the field is only explicitly loaded via CRMProduct.LoadFields(ConvertToCustomerAsset) when DestinationIsInserted is true. On the update path (DestinationIsInserted = false), if the field was not already part of the record's loaded field set from an earlier partial-field synchronization step, reading it can raise a 'field has not been loaded' runtime error, causing the synchronization job to fail. Call LoadFields(ConvertToCustomerAsset) unconditionally before DisableCustomerAssetConversion, or have the helper ensure the field is loaded before reading it.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

                    DestinationRecordRef.SetTable(CRMProduct);
                    CRMProduct.LoadFields(ConvertToCustomerAsset);
                    DisableCustomerAssetConversion(CRMProduct, AdditionalFieldsWereModified);
                    DestinationRecordRef.GetTable(CRMProduct);

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new Item-to-CRM Product sync test (ItemSynchronizationDisablesCustomerAssetConversion) only exercises an already-coupled, pre-existing product via CreateCoupledItemAndProduct, so it never covers the new DestinationIsInserted = true branch added in OnAfterTransferRecordFields (the conditional LoadFields(ConvertToCustomerAsset) path taken when a CRM Product is newly created from an item). Add a test case that synchronizes an uncoupled item so a new CRM Product is inserted, and assert the resulting ConvertToCustomerAsset is correctly initialized/disabled.

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Upgrade}$

The new 'Item-CRM Product' synchronization branch and its Item-Product field mapping constant (ConvertToCustomerAsset = 'false') change the intended behavior for existing tenants: previously-coupled items and their CRM Products keep their pre-30.0 field mapping and Convert-to-Customer-Asset state until a user manually runs 'Reset Configuration' or a full resync occurs. No upgrade code migrates already-installed Integration Field Mapping rows or already-coupled CRM Product records to the new 'service items always synchronize' design, so the fix does not apply safely to tenants that upgrade without manual intervention.

Knowledge:

• microsoft/knowledge/upgrade/upgrade-codeunit-subtype.md
• microsoft/knowledge/upgrade/install-code-does-not-run-on-version-upgrade.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

The obsolete public test-library procedure IgnoreServiceItemsByConvertToCustomerAssetFlag (Microsoft.TestLibraries.DynamicsFieldService, FSIntegrationTestLibrary.Codeunit.al) is correctly marked [Obsolete('...', '30.0')], but its body was replaced with an empty no-op instead of continuing to forward to the previous implementation. During the deprecation window, existing external callers who still invoke this public procedure expecting IgnoreRecord to be set now silently receive unchanged behavior. Guidance on deprecating public members with the Obsolete lifecycle recommends preserving the prior behavior (e.g., keep forwarding to the codeunit's still-present implementation, or otherwise retain the previous decision) until the procedure is actually removed in a later release, rather than emptying it immediately upon obsoletion.

Knowledge:

• microsoft/knowledge/breaking-changes/deprecate-public-members-with-the-obsolete-lifecycle.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new 'Item-CRM Product' case branch in OnAfterTransferRecordFields has a DestinationIsInserted path that calls CRMProduct.LoadFields(ConvertToCustomerAsset) before disabling customer-asset conversion, but the new tests (ItemSynchronizationDisablesCustomerAssetConversion, ItemProductMappingDisablesCustomerAssetConversion) only exercise the already-coupled/update path via CreateCoupledItemAndProduct. No test drives CRMIntegrationTableSynch.SynchRecord through a path where the CRM Product record is newly inserted, so the DestinationIsInserted = true branch (and its LoadFields call) is not covered by this change.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6}