Business Central ChangeCompany: The Trigger Context Trap

A cross-company AL routine can read the expected customer and still be unsafe to write. The missing question is often where its triggers execute.

Microsoft documents a precise distinction: ChangeCompany redirects a record to another company's table data, while triggers still execute in the current company. This guide helps you make that distinction visible before approving a cross-company change. The checklist below is Bitta Apps engineering guidance, not a claim that every cross-company routine has a defect.

The record company and the execution company are separate questions

Think about a session working in Company A and a Customer record redirected to Company B. The record addresses Company B's data. That does not establish that triggered logic has moved to Company B. Microsoft explicitly describes this behavior in the ChangeCompany reference.

For a read-only lookup, this separation may be exactly what you intend. For a write that invokes business logic, review every dependency. A trigger might read a setup table through another record variable. Ask whether that variable addresses the intended company; do not infer the answer from the first record's successful lookup.

The method name is a helpful label, not an architecture review.

Make the distinction visible with a read-only diagnostic

Microsoft documents Record.CurrentCompany() for the company associated with a record and Database.CompanyName() for the current company name. Compare them explicitly rather than relying on a variable's name.

local procedure InspectCustomerCompany(TargetCompany: Text)
var
    TargetCustomer: Record Customer;
    ContextMsg: Label 'Execution company: %1. Record company: %2.';
    AccessErr: Label 'Unable to redirect the customer record to %1.';
begin
    if not TargetCustomer.ChangeCompany(TargetCompany) then
        Error(AccessErr, TargetCompany);

    Message(ContextMsg, Database.CompanyName(), TargetCustomer.CurrentCompany());
    Clear(TargetCustomer);
end;

This original snippet illustrates company context without inserting, modifying, or deleting data. It is a manual diagnostic, not a complete production workflow or a test of a posting process. It has been reviewed against the documented signatures but has not been compiled in a Business Central environment. Compile and run it in your own sandbox with the correct symbols and permissions before adapting it.

Use a valid target company that differs from the session company. For this diagnostic, reject an empty target name rather than treating it as a useful test case. The CompanyName reference also notes that it can return an empty string when no company is selected; a production design should handle its actual execution context deliberately.

Review the trigger path before the write path

Record.Validate invokes the specified field's OnValidate trigger. Record.Modify has a RunTrigger parameter: true runs OnModify, while its default false does not run that trigger. These method-level facts make the company-context distinction relevant to code review.

Start at the entry point and follow the fields, table triggers, and called routines actually involved. Write down the record company for the data being changed and the company context for dependent reads. Include setup lookups and any additional record variables the logic uses. A routine that only demonstrates a successful Find is not evidence that its validation or posting behavior is correct.

Do not treat switching off OnModify as a general repair. Decide which business rules the operation requires and design around those rules. If an operation needs target-company execution context, review an approach that explicitly provides that context instead of assuming ChangeCompany supplies it. The appropriate architecture depends on the operation and environment; this article does not provide a generic cross-company posting recipe.

A focused sandbox review checklist

1. Define the intent. Is this a lookup, a controlled data change, or a business operation with validation and posting? Document which company should supply each dependency.
2. Use deliberately different test data. Give the sandbox companies distinguishable records and setup. Matching setup can hide a dependency on the wrong company.
3. Check permissions with the intended identity. ChangeCompany respects the user's access rights. An administrator's successful diagnostic is not a substitute for testing the account that will run the workflow.
4. Inspect filters. Microsoft's reference says assigned filters transfer to the redirected record. Set or verify the filters your operation actually needs rather than assuming a company switch starts with a clean selection.
5. Trace triggered logic. Review field validation, OnModify where requested, and the routines reached from them. Record the intended company for setup and other data reads.
6. Test cleanup and reuse. The reference says Reset does not remove the company redirection. Clear or another ChangeCompany call can deselect it; omitting the company argument changes back to the current company. Make reuse intentional.
7. Record the evidence. Preserve the scenario, execution identity, expected company choices, and observed results in the change review. Recheck affected behavior when the extension changes.

For more on structuring regression coverage, see our AL test automation guide. Treat the context checks above as inputs to your own tests, not as proof that an untested workflow is safe.

The decision before approving a cross-company change

A useful review should answer: which company does the record address, where will triggered logic execute, and which company's data should each dependency read? If any answer remains implicit, hold the write workflow until you can demonstrate it in a sandbox.

Keep the diagnostic read-only, make the dependency map explicit, and approve the business operation on evidence rather than a successful lookup. If you need help reviewing a specific extension design, book a call with Bitta Apps.