AL Method Attributes

Overview of Microsoft Dynamics 365 Business Central

This document explains all commonly used method attributes in AL, why they exist, how they affect runtime behavior, and how they should be used in real Business Central extensions.

Method attributes are not syntax sugar. They are architectural controls enforced by the Business Central platform.

They decide:

• Who can call a method
• From where it can be called
• Whether it is visible to other extensions
• Whether it can be accessed externally
• How errors behave
• How long a method is supported

Incorrect usage of method attributes is one of the main reasons extensions become unstable, tightly coupled, or upgrade-unsafe.


What Are Method Attributes in AL?

Method attributes are metadata instructions applied to procedures. They are written in square brackets ([ ]) and placed directly above a procedure definition.

They do not change the internal logic of the procedure. Instead, they tell the Business Central runtime how that procedure should be treated.

In simple terms:

Logic = what the procedure does
Attribute = how the platform allows it to behave

Why Method Attributes Exist in Business Central

Business Central is:

• Cloud-first
• Multi-tenant
• Extension-based
• Continuously upgraded

In such an environment, unrestricted method access would be dangerous. Method attributes exist to enforce:

• Encapsulation
• Extension isolation
• Safe integrations
• Backward compatibility
• Predictable execution

They are a core part of Business Central’s upgrade-safe design philosophy.

Classification of Method Attributes

For practical understanding, method attributes can be grouped into five categories:

1. Visibility and access control
2. Extension-to-extension communication
3. Integration and service exposure
4. Event handling
5. Runtime behavior and lifecycle control

Each category is explained in detail below.

1. Visibility and Access Control Attributes

These attributes control who can call a method and from where.

Internal

The Internal attribute restricts a method so it can be called only from within the same extension.

Example: Using Internal

AL

[Internal]
procedure CalculateInternalMargin(): Decimal
begin
    exit(500.00);
end;
    
Why it exists

Without Internal, methods can accidentally become accessible across extensions, creating hidden dependencies.

When to use

• Helper methods
• Shared logic within the same app
• Core calculations that must not be reused externally

Best practice

Most reusable logic inside an extension should be Internal by default.

Local (implicit behavior)

A local procedure is only accessible within the same object.

Example: Using Local Scope

AL

local procedure ValidateLine()
begin
end;
    

This is the strongest form of encapsulation.

Use when

• Logic is object-specific
• Reuse is not required

Scope = OnPrem

Restricts a method to on-premises environments only.

Example: Using Scope = OnPrem

AL

[Scope('OnPrem')]
procedure ReadLocalFile()
begin
    // File system access
end;
    
Why it exists

Cloud environments do not allow local file system or OS-level access.

Use when

• File handling
• Local hardware integration
• Legacy systems

This attribute prevents cloud publishing errors.

2. Extension-to-Extension Communication Attributes

These attributes control how other extensions interact with your logic.

External

The External attribute exposes a method to other extensions.

Example: Using External

AL

[External]
procedure CalculateCommission(Amount: Decimal): Decimal
begin
    exit(Amount * 0.05);
end;
    
Why it exists

Some extensions act as shared libraries or frameworks.

Use when

• Providing reusable logic intentionally
• Building shared utilities
• Designing app ecosystems

Risk

Overuse causes:

• Tight coupling
• Breaking changes
• Difficult upgrades

Only expose what you are prepared to support long-term.

Internal vs External (Design Rule)

• Internal → reusable inside the extension
• External → reusable by others (public API)

If unsure, choose Internal.

3. Integration and Service Exposure Attributes

These attributes expose AL methods outside Business Central.

ServiceEnabled

The ServiceEnabled attribute exposes a method as a web service endpoint.

Example: Using ServiceEnabled

AL

[ServiceEnabled]
procedure CreateCustomer(CustomerNo: Code[20]; Name: Text[100])
begin
    // Customer creation logic
end;
    
Why it exists

ERP systems must integrate with:

• Web portals
• Mobile apps
• Middleware
• External systems

Important rules

• Methods must be stateless
• Input validation is mandatory
• Security permissions must be enforced

Use when

• Creating APIs
• Triggering ERP logic externally

Do NOT use

• For internal logic
• For UI-dependent behavior

ServiceEnabled vs API Pages

• ServiceEnabled → method-based services
• API Pages → data-centric REST APIs

Choose based on integration design.

4. Event-Related Method Attributes

These attributes are the foundation of upgrade-safe extensions.

EventSubscriber

The EventSubscriber attribute allows a method to react to system or application events.

Example: Using EventSubscriber

AL

[EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterInsertEvent', '', false, false)]
local procedure OnCustomerInserted(var Rec: Record Customer)
begin
    Message('Customer %1 created.', Rec."No.");
end;
    
Why it exists

Direct modification of standard code is not allowed.

Key characteristics

• Method is never called directly
• Triggered by platform events
• Multiple subscribers allowed

Use when

• Extending standard behavior
• Adding validations
• Triggering automation

Event subscribers are the preferred extension mechanism in AL.

5. Runtime Behavior and Lifecycle Control Attributes

These attributes control how methods behave during execution and over time.

TryFunction

The TryFunction attribute allows a method to fail without throwing a runtime error.

Example: Using TryFunction

AL

[TryFunction]
procedure TryPostInvoice()
begin
    Error('Posting failed');
end;
    
How it works

• Errors are suppressed
• Caller checks success or failure

Example: Using if with TryFunction

AL

if TryPostInvoice() then
    Message('Success')
else
    Message('Failed');
    
Use when

• Batch processing
• Background jobs
• Integrations
• Retry logic

Do NOT use

• To hide bad logic
• To bypass validations

Obsolete

Marks a method as deprecated.

Example: Using Obsolete

AL

[Obsolete('Use CalculateNewDiscount instead', '23.0')]
procedure CalculateOldDiscount()
begin
end;
    
Why it exists

Extensions evolve. Removing methods immediately breaks dependent code.

What it does

• Shows compiler warnings
• Guides developers to new logic
• Preserves backward compatibility

This is essential for long-lived extensions.

ObsoleteState (Advanced)

Controls severity:

• Pending
• Removed

Used in advanced versioning strategies.

How Method Attributes Influence AL Architecture

Method attributes force developers to think in terms of:

• API boundaries
• Encapsulation
• Upgrade safety
• Responsibility separation

Well-designed extensions:

• Expose very few External methods
• Prefer Internal + events
• Use ServiceEnabled sparingly
• Deprecate instead of deleting

Common Developer Mistakes

• Marking everything as External
• Using ServiceEnabled without security
• Using TryFunction to mask errors
• Forgetting to deprecate old methods
• Ignoring scope differences

These mistakes lead to fragile extensions.

Summary

Method attributes in AL define how procedures are exposed, restricted, executed, and maintained. They are a cornerstone of Business Central’s extension architecture.

Understanding method attributes allows developers to:

• Build upgrade-safe solutions
• Control integration boundaries
• Avoid tight coupling
• Maintain extensions over multiple versions

Mastery of method attributes separates basic AL coders from professional Business Central developers.

Hot Topics in Business Central

Next Steps in Business Central