AL Method Attributes
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 AttributesThese attributes control who can call a method and from where.
InternalThe Internal attribute restricts a method so it can be called only from within the same extension.
Example: Using Internal
[Internal]
procedure CalculateInternalMargin(): Decimal
begin
exit(500.00);
end;
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
local procedure ValidateLine()
begin
end;
This is the strongest form of encapsulation.
Use when
• Logic is object-specific
• Reuse is not required
Restricts a method to on-premises environments only.
Example: Using Scope = OnPrem
[Scope('OnPrem')]
procedure ReadLocalFile()
begin
// File system access
end;
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 AttributesThese attributes control how other extensions interact with your logic.
ExternalThe External attribute exposes a method to other extensions.
Example: Using External
[External]
procedure CalculateCommission(Amount: Decimal): Decimal
begin
exit(Amount * 0.05);
end;
Some extensions act as shared libraries or frameworks.
Use when
• Providing reusable logic intentionally
• Building shared utilities
• Designing app ecosystems
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 AttributesThese attributes expose AL methods outside Business Central.
ServiceEnabledThe ServiceEnabled attribute exposes a method as a web service endpoint.
Example: Using ServiceEnabled
[ServiceEnabled]
procedure CreateCustomer(CustomerNo: Code[20]; Name: Text[100])
begin
// Customer creation logic
end;
ERP systems must integrate with:
• Web portals
• Mobile apps
• Middleware
• External systems
• Methods must be stateless
• Input validation is mandatory
• Security permissions must be enforced
• Creating APIs
• Triggering ERP logic externally
• For internal logic
• For UI-dependent behavior
• ServiceEnabled → method-based services
• API Pages → data-centric REST APIs
Choose based on integration design.
4. Event-Related Method AttributesThese attributes are the foundation of upgrade-safe extensions.
EventSubscriberThe EventSubscriber attribute allows a method to react to system or application events.
Example: Using EventSubscriber
[EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterInsertEvent', '', false, false)]
local procedure OnCustomerInserted(var Rec: Record Customer)
begin
Message('Customer %1 created.', Rec."No.");
end;
Direct modification of standard code is not allowed.
Key characteristics
• Method is never called directly
• Triggered by platform events
• Multiple subscribers allowed
• Extending standard behavior
• Adding validations
• Triggering automation
Event subscribers are the preferred extension mechanism in AL.
5. Runtime Behavior and Lifecycle Control AttributesThese attributes control how methods behave during execution and over time.
TryFunctionThe TryFunction attribute allows a method to fail without throwing a runtime error.
Example: Using TryFunction
[TryFunction]
procedure TryPostInvoice()
begin
Error('Posting failed');
end;
• Errors are suppressed
• Caller checks success or failure
Example: Using if with TryFunction
if TryPostInvoice() then
Message('Success')
else
Message('Failed');
• Batch processing
• Background jobs
• Integrations
• Retry logic
• To hide bad logic
• To bypass validations
Marks a method as deprecated.
Example: Using Obsolete
[Obsolete('Use CalculateNewDiscount instead', '23.0')]
procedure CalculateOldDiscount()
begin
end;
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 ArchitectureMethod 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