Use SecretText type to protect credentials and sensitive textual values from being revealed
Important
This content is archived and is not being updated. For the latest documentation, go to What's new or changed in Business Central. For the latest release plans, go to Dynamics 365, Power Platform, and Cloud for Industry release plans.
| Enabled for | Public preview | General availability |
|---|---|---|
| Admins, makers, marketers, or analysts, automatically | 
Aug 16, 2023 |
Oct 2, 2023 |
Business value
With an increasing amount of integrations to external systems, it's not uncommon in AL code to work with secrets such as credentials and other sensitive textual values. Given the need to protect these from being revealed through debugging, the latter has often been blocked through resource exposure policies, at the cost of easy troubleshooting. To support enabling debugging, while protecting credentials and other sensitive textual values from being revealed, we are introducing a new SecretText type for variables. In addition, some of the common scenarios in the system app will get support for passing in SecretText parameters for credentials—for example, the HttpClient and Isolated Storage types.
Feature details
A new type, SecretText, has been added to protect credentials and other sensitive textual values from being revealed through debugging. The declaration syntax will be similar to the Text data type, with the sole difference that it won't support constraints on the length.
SecretText will be usable as a:
- Variable value
- Return value
- Parameter value
Its use will be limited to carrying, for example, credentials from the point of creation to the destination method. The destination method must accept a SecretText value.
Any text type will be assignable to the SecretText type as long as it can be converted to the Text type. The SecretText type encapsulates a Text type. If a Code or other text type is to be stored, it'll be converted into the Text type. A Dotnet string type will also be convertible to SecretText. However, a constant or other types won't be assignable to a SecretText type.
For exceptional cases where it must be used as a text, a built-in Unwrap method will be supported. This will only be usable when the project scope is on-premises. Given on-premises only, it will be allowed outside of boundaries of a procedure marked as NonDebuggable, but it will result in a warning, and can thus also be blocked through the use of a ruleset for specific projects.
Initially, events won't support SecretText parameters; however, triggers will. The latter scenario is to support the case of control add-ins like the OAuth control add-in to return the credentials in a secure container.
In the system app, HttpClient will get support for passing SecretText parameters—for example, for credentials.
In the following example, the return value and parameter will not be debuggable:
See also
Protecting sensitive values with the SecretText data type (docs)