Chapter 3: First Steps with AL

Objectives

By the end of this chapter you will be able to:

• Create a minimal AL extension with a table, page, and codeunit
• Explain the role of each object in the extension architecture
• Publish and test your first end-to-end interaction
• Use basic debugging to validate behavior before adding complexity

3.1 Build a minimal vertical slice

Your first AL project should contain one small, complete flow:

• A table for data
• A page to view and edit records
• A codeunit procedure called from the page

Chapters 7 to 16 use the same architecture, and it keeps business logic from piling up in page triggers.

3.2 Keep logic placement intentional

From day one, follow this rule for where logic goes:

• Table trigger: data integrity constraints
• Codeunit procedure: reusable business logic
• Page action: only the entry point that calls codeunit logic

Chapter 9 formalizes this pattern, and Chapter 14 tests it.

3.3 Publish, run, and inspect

After you publish with F5:

1. Open your page in Business Central.
2. Create sample data.
3. Trigger your page action.
4. Confirm that the resulting table changes are correct.

If something is wrong, look at what is happening in the debugger before you edit several files.

3.4 Basic debugging loop

Keep the debugging loop tight:

1. Reproduce one issue.
2. Place breakpoints at object boundaries (page action, then codeunit, then table trigger).
3. Inspect Rec values before and after procedure calls.
4. Change one thing, retest, and repeat.

With this habit in place, the Rec vs xRec topic in Chapter 9 is much easier to follow.

Chapter summary

In this chapter you:

• Built and published a minimal extension slice
• Practiced correct logic placement across table, page, and codeunit
• Checked behavior by running the code instead of relying on assumptions
• Set up a debugging workflow you can repeat in later chapters

Tasks

1. Create a starter object set. Add one table, one page, and one codeunit.
2. Wire an action. Add a page action that calls a codeunit procedure.
3. Validate update flow. Confirm the called procedure changes data as expected.
4. Try it yourself. Record one bug you found with a breakpoint and what value inspection revealed.

Check your work: your flow should resemble the Chapter 8→9 pattern where a page action invokes codeunit logic instead of embedding business rules inline.