[Event Request] Codeunit 7205 CDS Int. Table. Subscriber OnBeforeSetSalespersonPurchaserCode

[elweilando]

Why do you need this change?

When data is written to the Salesperson/Purchaser table via Dataverse synchronization, the codeunit generates a fixed code that cannot be modified or defined through a number series. As a result, synchronization can only use this predefined pattern as the code.

It would make sense to provide an event here so that developers can intervene in the process.

Describe the request

The pattern is hardcoded in the codeunit

There is no chance to change this. Also in the calling events, there is no option to change the code before the insert.
Please add an event before the code is set, which can be controlled via Handled so that the standard logic can be skipped.

Internal work item: [AB#635600](https://dynamicssmb2.visualstudio.com/1fcb79e7-ab07-432a-a3c6-6cf5a88ba4a5/_workitems/edit/635600)

[AleksandricMarko]

Hi @elweilando,

Thanks for submitting this extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Exact proposed code change with surrounding context: Please include the exact AL code change you want, with enough surrounding code to show the intended insertion point and flow.
• Performance considerations: Please describe the expected execution frequency of this logic and any performance impact of adding the IsHandled event.
• Data sensitivity review: Please explain what data would be exposed through the event and confirm whether any sensitive data concerns exist.
• Multi-extension interaction or conflict risks: Please describe how multiple extensions should behave if more than one subscriber wants to handle this logic, and why an IsHandled pattern is safe here.

Please update the issue with the missing details. We'll automatically re-analyze once updated.

[elweilando]

In Codeunit 7205 CDS. Int. Table. Subscriber is the Salesperson/Purchase Code Pattern hardcoded

        NewCodePatternTxt: Label 'SP NO. %1', Locked = true;
        SalespersonPurchaserCodeFilterLbl: Label 'SP NO. 0*', Locked = true;

There is no chance to change this. Also in the calling events, there is no option to change the code before the insert.

local procedure UpdateSalesPersOnBeforeInsertRecord(var DestinationRecordRef: RecordRef)
    var
        SalespersonPurchaser: Record "Salesperson/Purchaser";
        CRMIntegrationManagement: Codeunit "CRM Integration Management";
        DestinationFieldRef: FieldRef;
        NewCode: Text;
    begin
        if not (CRMIntegrationManagement.IsCDSIntegrationEnabled() or CRMIntegrationManagement.IsCRMIntegrationEnabled()) then
            exit;

        // We need to create a new code for this SP.
        // To do so we just do a SP NO. A
        SalespersonPurchaser.SetFilter(Code, SalespersonPurchaserCodeFilterLbl);
        if SalespersonPurchaser.FindLast() then
            NewCode := IncStr(SalespersonPurchaser.Code)
        else
            NewCode := StrSubstNo(NewCodePatternTxt, '00001');

        DestinationFieldRef := DestinationRecordRef.Field(SalespersonPurchaser.FieldNo(Code));
        DestinationFieldRef.Value := NewCode;
    end;

Please add an event before the code is set, which can be controlled via Handled so that the standard logic can be skipped.

local procedure UpdateSalesPersOnBeforeInsertRecord(var DestinationRecordRef: RecordRef)
    var
        SalespersonPurchaser: Record "Salesperson/Purchaser";
        CRMIntegrationManagement: Codeunit "CRM Integration Management";
        DestinationFieldRef: FieldRef;
        NewCode: Text;
IsHandled: Boolean;
    begin
        if not (CRMIntegrationManagement.IsCDSIntegrationEnabled() or CRMIntegrationManagement.IsCRMIntegrationEnabled()) then
            exit;

OnBeforeCreateNewSalespersonPurchaserCode(DestinationRecordRef, NewCode, IsHandled);

if not IsHandled then begin
        // We need to create a new code for this SP.
        // To do so we just do a SP NO. A
        SalespersonPurchaser.SetFilter(Code, SalespersonPurchaserCodeFilterLbl);
        if SalespersonPurchaser.FindLast() then
            NewCode := IncStr(SalespersonPurchaser.Code)
        else
            NewCode := StrSubstNo(NewCodePatternTxt, '00001');
end;

        DestinationFieldRef := DestinationRecordRef.Field(SalespersonPurchaser.FieldNo(Code));
        DestinationFieldRef.Value := NewCode;
    end;

local procedure OnBeforeCreateNewSalespersonPurchaserCode(DestinationRecordRef: RecordRef; var NewCode: Code[20]; var IsHandled: Boolean)

[AleksandricMarko]

Hi @elweilando,

Thanks for submitting this extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Performance considerations: Please describe the expected execution frequency of this logic and any performance impact of adding the IsHandled event.
• Data sensitivity review: Please explain what data would be exposed through the event and confirm whether any sensitive data concerns exist.
• Multi-extension interaction or conflict risks: Please describe how multiple extensions should behave if more than one subscriber wants to handle this logic, and why an IsHandled pattern is safe here.
• RecordRef justification: The proposed event includes DestinationRecordRef: RecordRef. Please explain exactly how subscribers would use this RecordRef, why a simpler parameter set would not be enough, and what alternatives you considered before choosing RecordRef.

Please update the issue with the missing details. We'll automatically re-analyze once updated.

[elweilando]

Performance considerations: This is difficult to estimate precisely. The event is part of the Dataverse synchronization process, specifically within the mapping from Dataverse User to Salesperson/Purchaser:
https://learn.microsoft.com/en-us/dynamics365/business-central/admin-synchronizing-business-central-and-sales#standard-table-mapping-for-synchronization

The execution frequency depends on the number of users being synchronized. In typical scenarios, this logic is only triggered during synchronization runs for newly created records and therefore should not have a significant performance impact. The additional IsHandled event check itself is lightweight and consistent with common Business Central extensibility patterns.

Data sensitivity review: The exposed data is limited to the fields included in the synchronization mapping:
https://learn.microsoft.com/en-us/dynamics365/business-central/admin-how-to-modify-table-mappings-for-synchronization

DestinationRecordRef contains the standard fields of the Salesperson/Purchaser table:
https://learn.microsoft.com/de-de/dynamics365/business-central/application/base-application/table/microsoft.crm.team.salesperson-purchaser

In addition, fields introduced by customer-specific extensions or AppSource apps may also be present. The event does not expose any additional data beyond what is already available during the synchronization process itself.

Multi-extension interaction or conflict risks: If multiple extensions subscribe, there is no guaranteed cooperative merge of replacement logic. That is expected and acceptable for this type of event: only one subscriber should take ownership. Extensions that do not own the scenario must exit when IsHandled is already set. Therefore, the pattern avoids cumulative side effects rather than enabling them.

This approach is aligned with the general AL event guidance:
https://alguidelines.dev/docs/agentic-coding/vibe-coding-rules/al-events/

RecordRef justification: The calling function UpdateSalesPersOnBeforeInsertRecord already contains the DestinationRecordRef information populated by the upstream synchronization flow:

• Codeunit 7205 "CDS Int. Table. Subscriber" → HandleOnBeforeInsertRecord
• Codeunit 5345 "Integration Rec. Synch. Invoke" → InsertRecord
• Codeunit 5345 "Integration Rec. Synch. Invoke" → SynchRecord

Using RecordRef allows subscribers to work with the complete destination record, including custom fields introduced by extensions, without requiring changes to the event signature whenever the underlying table structure changes.

A simpler parameter set would not provide the same level of flexibility or future extensibility, especially for custom synchronization scenarios.

Additional background: In standard Business Central processes, number series are typically used to support customer-specific numbering concepts. In this specific scenario, however, the numbering is currently hardcoded.

Providing this event would also make it possible to implement the same numbering process that is already used in the higher-level calling function Codeunit 7205 "CDS Int. Table. Subscriber" HandleOnBeforeInsertRecord

case SourceDestCode of
            'Customer-CRM Account',
            'Contact-CRM Contact',
            'Vendor-CRM Account':
                begin
                    SetCompanyId(DestinationRecordRef);
                    SetOwnerId(SourceRecordRef, DestinationRecordRef);
                end;
            'Currency-CRM Transactioncurrency':
                SetDefaultSymbolOnCRMTransactioncurrencyIfEmpty(DestinationRecordRef);
            'CRM Account-Customer':
                if ConfigTemplateCode <> '' then
                    if ConfigTemplateHeader.Get(ConfigTemplateCode) then
                        CustomerTemplMgt.FillCustomerKeyFromInitSeries(DestinationRecordRef, ConfigTemplateHeader);
            'CRM Account-Vendor':
                if ConfigTemplateCode <> '' then
                    if ConfigTemplateHeader.Get(ConfigTemplateCode) then
                        VendorTemplMgt.FillVendorKeyFromInitSeries(DestinationRecordRef, ConfigTemplateHeader);
            'CRM Product-Item':
                if ConfigTemplateCode <> '' then
                    if ConfigTemplateHeader.Get(ConfigTemplateCode) then
                        ItemTemplMgt.FillItemKeyFromInitSeries(DestinationRecordRef, ConfigTemplateHeader);
        end;

        if DestinationRecordRef.Number() = DATABASE::"Salesperson/Purchaser" then
            UpdateSalesPersOnBeforeInsertRecord(DestinationRecordRef);

[AleksandricMarko]

✅ Analysis complete - approved for implementation

---

Implementation:

Add a new IsHandled integration event in the UpdateSalesPersOnBeforeInsertRecord() procedure of Codeunit 7205 CDS Int. Table. Subscriber before the standard Salesperson/Purchaser code is generated.

Location in UpdateSalesPersOnBeforeInsertRecord() procedure (around line 1396):

if not (CRMIntegrationManagement.IsCDSIntegrationEnabled() or CRMIntegrationManagement.IsCRMIntegrationEnabled()) then
    exit;

IsHandled := false;
OnUpdateSalesPersOnBeforeInsertRecordOnBeforeCreateNewSalespersonPurchaserCode(DestinationRecordRef, NewCode, IsHandled);
if not IsHandled then begin
    // We need to create a new code for this SP.
    // To do so we just do a SP NO. A
    SalespersonPurchaser.SetFilter(Code, SalespersonPurchaserCodeFilterLbl);
    if SalespersonPurchaser.FindLast() then
        NewCode := IncStr(SalespersonPurchaser.Code)
    else
        NewCode := StrSubstNo(NewCodePatternTxt, '00001');
end;

DestinationFieldRef := DestinationRecordRef.Field(SalespersonPurchaser.FieldNo(Code));
DestinationFieldRef.Value := NewCode;

Event Publisher (add at the end of the codeunit with other events):

[IntegrationEvent(false, false)]
local procedure OnUpdateSalesPersOnBeforeInsertRecordOnBeforeCreateNewSalespersonPurchaserCode(DestinationRecordRef: RecordRef; var NewCode: Code[20]; var IsHandled: Boolean)
begin
end;

---

File: CDSIntTableSubscriber.Codeunit.al