Hire Business Central AL developers: a practical assessment guide

Begin with the development backlog, not a technology list

“AL, APIs and integrations” is too broad to distinguish candidates. Group your backlog into extension changes, reports, interface work, upgrade corrections and performance investigation. Identify which tasks are ready for development and which still need a functional decision. This reveals the experience you need immediately.

For each representative task, record the affected process, input data, expected behavior and dependencies. A developer joining an implementation with mature designs faces a different job from someone taking over undocumented customizations. Say whether the person will receive reviewed specifications or must help clarify requirements with users.

Request Business Central AL developer profiles with examples aligned to those tasks. A candidate with substantial document layout experience may still need support on transactional extensions. Ask what they personally implemented, who reviewed it and how the change was maintained later. Specific ownership matters more than the overall size of a project on a résumé.

Design a small assessment with business consequences

Use a fictional requirement that can be discussed within a reasonable session. For example, a hypothetical distributor wants a reference field with validation and visibility on a relevant document. Provide enough context for the candidate to explain the design, then introduce an exception: existing records have missing values and some users may view but not edit the information.

The assessment should expose reasoning without asking for unpaid production work. Let the candidate outline objects, validation placement, permissions and tests. If a short coding task is used, state the time expectation and evaluation criteria in advance. Do not require access to confidential customer environments.

Watch the sequence of questions. A capable developer asks when validation applies, whether posting is affected, how existing data is treated and what users should see on failure. These questions demonstrate awareness that an ERP field is part of a process, not merely a visual addition to a page.

Review maintainability as a business requirement

Readable code lowers the cost of future investigation. Ask the candidate to explain naming, separation of responsibilities and how they keep business rules understandable. Present a small sanitized code sample with mixed validation and presentation concerns, then ask what they would change and why.

Discuss extension dependencies and how an incoming developer learns the existing architecture. They should identify the applications involved, review source availability and avoid assuming that every installed component can be modified. Ask how they document an unavoidable dependency or a limitation discovered during development.

Version control deserves practical questions. Who reviews changes? What constitutes a releasable package? How are urgent fixes separated from unfinished features? You are looking for a process suited to your team, not a particular tool name. A strong answer connects a development task with its review, acceptance and release record so another person can understand what changed months later.

Make error handling and API judgment visible

Many Business Central developer roles include external interfaces. Microsoft provides built-in APIs and supports custom APIs using AL. A candidate should first evaluate available endpoints against the required transaction before assuming a custom interface is necessary. That decision affects both effort and maintenance.

Use a hypothetical order import that receives the same request twice. Ask how the solution recognizes a previous attempt, reports a business validation failure and avoids creating duplicates during retries. Do not insist on one universal design; evaluate whether the candidate asks about identifiers, ownership, volumes and recovery responsibilities.

When interfaces dominate the assignment, compare Business Central integration developers rather than treating integration as a minor AL skill. The person may need experience beyond Business Central, including middleware operations and external API contracts. Confirm which system they will own and who can investigate failures on the other side.

Use a scorecard that distinguishes evidence from confidence

Score observable evidence immediately after the interview. Keep technical correctness separate from communication and availability so a polished presentation does not conceal missing delivery skills. Where the candidate has not used your exact toolchain, assess transferable practice and identify the onboarding needed.

The following scorecard can be adapted to seniority. A junior developer can be a good fit when reviewed tasks and experienced guidance are available. A sole technical owner requires deeper architectural judgment and stronger operational experience. Hiring a junior person into an unsupported senior role creates a mismatch that a longer technology checklist will not resolve.

Ask how the developer proves a change is safe

Testing should follow the consequence of the change. A new display field may need a small check, while posting-related behavior deserves wider scenarios. Ask the developer to explain positive cases, invalid inputs, permissions and interactions with existing extensions. The answer should fit the change rather than promise identical testing for every task.

For upgrade readiness, ask how the team notices compatibility issues, reviews warnings and validates business flows in an appropriate test environment. Do not accept “extensions are upgrade safe” as a complete assurance. Compatibility depends on the implementation and the surrounding applications, and needs evidence.

Ask about troubleshooting a failure that cannot be reproduced immediately. Microsoft distinguishes tools used during development from telemetry used to investigate events after they occur. A developer need not memorize every diagnostic command, but should know what information to collect, how to narrow the cause and when to involve an administrator or another application owner.

Choose a hiring model that supports technical review

Hourly Model works for a prioritized backlog, code review assistance or occasional specialist investigation. Establish a reviewable unit of progress, such as an approved design, tested change or documented finding. Time records alone do not show whether the application is becoming more maintainable.

Project Based is appropriate when extension scope and acceptance criteria are stable. Include technical documentation, source delivery and release support in the agreed outcome. Identify assumptions about third-party apps and customer test availability so neither side treats an unresolved dependency as an invisible obligation.

Dedicated Resource is useful for an ongoing roadmap or implementation stream. Assign an internal product owner and technical reviewer, even if the developer is experienced. For delivery partners serving Canada, the United States or European clients, agree overlapping review time and escalation arrangements. Dedicated capacity should not mean that the developer is permanently waiting for decisions outside their control.

Set the first month up for evidence, not surprises

Start with repository access, environment orientation and a walkthrough of the most important customizations. Keep production access separate from development needs. Give the developer a small representative task that exercises your real review process and reveals documentation gaps without placing a major release at risk.

Agree what the first review should show: understanding of the codebase, a completed bounded change, clear test evidence and a list of dependencies that need attention. If those outputs expose wider architectural issues, decide whether to add Business Central technical consulting support before increasing the development queue.

Record practical agreements about ownership, leave coverage and handover. Keep source, build instructions and deployment notes in customer-controlled locations where appropriate. At the end of the first month, assess completed outcomes, quality of questions and responsiveness to feedback. These signals are more useful than counting commits or rewarding speed without checking correctness.

• Assessment context: representative task and clear evaluation criteria.
• Review readiness: source access, reviewer availability and acceptance owner.
• Handover evidence: build notes, tests and release documentation.