SessionSettings, My Settings, Your Settings?

In this video, I try to figure out how the SessionSettings data type works. It’s not really working as documented, but is still very useful, check the video!

https://youtu.be/y-opua8KQ1k

In this video, Erik explores the SessionSettings data type in AL — a complex type that lets you programmatically control the settings found under “My Settings” in Business Central. He walks through changing companies, languages, time zones, and more, while uncovering some quirks and limitations along the way.

What Are “My Settings” in Business Central?

In Business Central, you can access “My Settings” either by pressing Alt+T (the power user way) or by navigating through the menu. This settings page lets you configure:

  • Role (aka Profile)
  • Company
  • Work Date
  • Region
  • Language
  • Time Zone
  • Notifications and Teaching Tips

What many developers don’t realize is that you can control these settings programmatically from AL using the SessionSettings data type.

The SessionSettings Data Type

The SessionSettings type is classified as a “complex data type” in the documentation. It works in a somewhat unusual pattern compared to most other constructs in AL and Business Central.

To use it, you first declare a variable of type SessionSettings, then call Init() to load the current session’s settings into it. From there, you can modify properties and ultimately request a session update.

Basic Pattern: Switching Companies

Here’s the minimal version of switching companies:

var
    s: SessionSettings;
begin
    s.Init();
    s.Company('My Company');
    s.RequestSessionUpdate(false);
end;

There are three key steps:

  1. Init() — Loads the current session settings into the variable.
  2. Set a property — For example, Company('My Company') to specify the target company.
  3. RequestSessionUpdate() — Triggers the actual session reload. The boolean parameter controls whether the change is saved to the user’s personalization.

An important point: if you skip RequestSessionUpdate(), nothing happens. You’ve only changed the value in the variable — the session itself remains unchanged.

RequestSessionUpdate: The Session Reloads

When RequestSessionUpdate() is called, the session reloads. This has a critical implication: any code after this call may not execute reliably. Erik demonstrates this by placing a Message() call after the update request — the message briefly flashes on screen before the session restarts and wipes it away.

He even tests with a Sleep(10000) call to see what happens:

s.Init();
s.Company('My Company');
s.RequestSessionUpdate(false);
Sleep(10000); // Don't do this!
Message('Hello YouTube');

While the sleep did complete in his test, Erik is clear: you should not rely on any code running after RequestSessionUpdate(). It should be the last statement in your execution flow.

The Save Parameter: True vs. False

The boolean parameter on RequestSessionUpdate() controls whether the setting change is persisted to the user’s profile personalization:

  • false — The change applies only to the current session. When the user starts a new session, they’ll be back to their original settings.
  • true — The change is saved to the user’s profile, so subsequent sessions will also reflect the new setting.

For example, if you switch to “My Company” with false, the next time you open Business Central you’ll be back in your original company (e.g., “Cronus”). With true, you’ll stay in “My Company” across sessions.

Available Properties

The SessionSettings type exposes several properties you can modify:

  • Company — Switch the active company
  • LanguageId — Set the UI language (e.g., 1030 for Danish)
  • LocaleId — Set the region/locale
  • ProfileId — Set the role/profile
  • ProfileAppId — Specify the extension that owns the profile
  • ProfileSystemScope — Set the scope (may not work on cloud)
  • Timezone — Set the time zone using Windows time zone IDs

The Full Source Code

Here’s the complete page extension Erik built for testing. It adds two promoted actions to the Customer List — one to apply session settings and one to verify the current time zone:

pageextension 50138 CustomerListExt extends "Customer List"
{
    actions
    {
        addfirst(processing)
        {
            Action(Test)
            {
                Caption = 'Try';
                ApplicationArea = All;
                Promoted = true;
                PromotedCategory = Process;
                PromotedOnly = true;
                PromotedIsBig = true;
                trigger OnAction()
                var
                    s: SessionSettings;
                begin
                    s.Init();
                    s.LanguageId(1030);
                    s.RequestSessionUpdate(true);
                end;
            }
            Action(Test2)
            {
                Caption = 'Verify';
                ApplicationArea = All;
                Promoted = true;
                PromotedCategory = Process;
                PromotedOnly = true;
                PromotedIsBig = true;
                trigger OnAction()
                var
                    s: SessionSettings;
                    T: Codeunit "Type Helper";
                begin
                    Message('Is %1 equal to %2',
                        CurrentDateTime(),
                        T.FormatUtcDateTime(CurrentDateTime(), '', ''));
                end;
            }
        }
    }
}

Verifying Time Zones with Type Helper

The “Verify” action demonstrates a useful technique for checking what time zone Business Central thinks it’s operating in. The DateTime data type in BC is stored as UTC but displayed in the user’s time zone. By comparing CurrentDateTime() (displayed in local time) with TypeHelper.FormatUtcDateTime() (formatted as UTC), you can see the offset — or confirm they’re the same when set to UTC.

Quirks and Limitations Discovered

Erik discovered several issues while experimenting with SessionSettings:

Time Zone: Doesn’t Work Temporarily

Setting the time zone with RequestSessionUpdate(false) simply didn’t work — the session still showed the original time zone. Only when using true (saving to the profile) did the time zone actually change. This contradicts the expectation that false would apply the change temporarily for the current session.

Language: Same Behavior

The same issue applies to language changes. Setting LanguageId(1030) (Danish) with false did not switch the language. Only with true did the session reload into Danish. It appears that the temporary (non-saving) mode only reliably works for company switching.

Web Service Sessions

The documentation mentions that SessionSettings can be used with web service sessions, but Erik was unable to make this work since you cannot reload a web service session. If you’ve found a way to make this work, Erik would love to hear about it.

Practical Use Case: Company Switching

The clear win for SessionSettings is programmatic company switching. For many users, switching companies is a frequent and tedious task — navigating to My Settings, selecting a different company, and waiting for the reload. With just three lines of AL code, you can build a much smoother experience:

var
    s: SessionSettings;
begin
    s.Init();
    s.Company('Target Company Name');
    s.RequestSessionUpdate(false);
end;

Imagine a scenario where you’re working with intercompany journals: you could post data and then immediately switch the user to the relevant company. Or if your data indicates which company a user needs to work in, you can provide an on-screen action that switches them there instantly.

A Quick Note on the Next() Function

During a brief tangent (directed at fellow BC community member Waldo), Erik clarified how the Next() function works on records: the parameter specifies how many steps to move. Next(1) moves one record forward (same as calling Next with no parameters). You could use Next(10) to jump 10 records ahead, or Next(-1) to go backwards. It returns 0 when it can’t move further, which is the standard loop termination condition.

Summary

The SessionSettings data type in AL provides a way to programmatically control the settings found in “My Settings” in Business Central. Here’s what to remember:

  • Always call Init() first to load current settings into the variable.
  • RequestSessionUpdate() should be the last statement in your code — the session reloads after this call.
  • The boolean parameter controls whether changes are saved to the user’s profile (true) or are temporary (false).
  • Company switching works reliably with both true and false — this is the most practical use case.
  • Language, time zone, and locale changes appear to only work when saved to the profile (true), not as temporary session changes.
  • Web service session support is documented but unclear in practice.

Despite some quirks and documentation gaps, the ability to switch companies programmatically is a genuinely useful feature that can significantly improve the user experience in multi-company environments.

Picture of hougaard

hougaard