Business Central developer or functional consultant: who do you need?

Describe the outcome before choosing a job title

A request for a Business Central developer often begins with a business frustration: purchase invoices take too long, production costs look wrong, or users maintain a spreadsheet outside the ERP. None of those symptoms proves that new code is necessary. A posting setup, incomplete master record, missing training step or unclear approval responsibility can produce the same visible problem.

Write down the transaction, affected users, expected result, current result and frequency. Add a sanitized example and identify when the process last worked correctly. Ask whether the issue appears in the standard application, an installed extension or an external connection. This brief gives an experienced specialist something concrete to investigate.

For an uncertain requirement, buy a bounded diagnosis first. Its output should classify the problem, describe options and identify the skills needed next. A short assessment can prevent a long development assignment from building around a process that should have been corrected.

What a functional consultant should own

A functional consultant connects operational requirements with application behavior. Typical responsibilities include workshops, process mapping, setup decisions, data requirements, test scenarios and user guidance. The consultant should explain why a proposed approach suits your business rather than simply show where a field appears on a screen.

Consider a hypothetical distributor whose purchasing team cannot understand the replenishment suggestions. A functional assessment would examine the planning policy, demand assumptions, item and location data, and how planners review exceptions. The consultant should work with purchasing and warehouse staff before concluding that a custom planning report is needed.

When that is your situation, review Business Central functional consultant profiles against the relevant workstream. Finance experience does not automatically establish manufacturing or warehouse expertise. Ask which processes the candidate personally designed, how decisions were approved and what evidence demonstrated that users could complete their work after implementation.

What an AL developer should own

An AL developer turns a defined application requirement into maintainable Business Central functionality. Microsoft documents AL as the language for Business Central applications. For hiring purposes, the important evidence is not only whether someone can create an object, but whether they understand extension boundaries, business validation, error handling and the consequences of a change.

A suitable development brief includes the business rule, affected transactions, acceptance criteria, permissions and expected exception behavior. The developer should challenge contradictions, estimate dependencies and identify what requires functional review. They should explain their approach to source control, testing, packaging and upgrades in terms your technical reviewer can assess.

A hypothetical custom approval condition might require development after standard options are evaluated. The developer should not independently decide the commercial approval policy. That remains a business decision, translated into unambiguous behavior with the consultant. Review Business Central AL developers when this technical ownership is the missing capability.

Use a decision table for mixed requirements

The table below is a hiring guide, not an assertion that every requirement has a single owner. A report request may need finance expertise to define figures, a developer to expose data and a reporting specialist to present it. The right starting role depends on the unanswered question.

Ask the proposed resource to explain what they would investigate before estimating. A candidate who immediately recommends customization without reviewing the process may create avoidable maintenance. Equally, repeated configuration workshops are unhelpful when the business rule is already approved and the actual gap is a broken extension. The goal is an explicit handoff, with one person accountable for each decision.

Interview with one realistic business scenario

Give both candidates the same short scenario and compare how they approach uncertainty. For example, a hypothetical manufacturer needs an additional validation before production consumption. Ask the functional candidate which policies, item data and operating exceptions must be understood. Ask the developer how they would locate a suitable extension point and prove that valid transactions remain unaffected.

Do not reward confidence alone. Look for useful questions, clear assumptions and an ability to distinguish known behavior from something that needs verification in your version. Request a walkthrough of anonymized deliverables where sharing is permitted. A functional design and a reviewed change can reveal more than a long list of technologies.

Assess communication as part of delivery skill. Can the candidate explain a risk to an operations manager without burying the decision in technical terms? Can they accept a review comment and revise their position? These behaviors matter especially when your internal subject experts have limited time.

Prevent the handoff gap between process and code

The common failure is a technically completed change that nobody can confidently accept. Avoid this by making the functional specification small, testable and jointly reviewed. Include sample inputs, expected outputs, invalid inputs, permissions, document states and any effect on downstream posting or reporting.

Name a business acceptance owner before development begins. The developer verifies the implementation; the functional consultant checks process behavior; the business owner confirms that the outcome meets the agreed need. These are complementary responsibilities, not three interchangeable approvals.

Keep a decision log for scope changes. If a user requests a new exception during testing, record whether it corrects a missed requirement or expands scope. Include documentation and support notes in the same task rather than treating them as optional administration. For broader changes, Business Central solution architecture expertise can help coordinate module boundaries and prevent separate specialists from making incompatible assumptions.

Match the engagement model to the uncertainty

The Hourly Model suits investigation, design review, occasional configuration help or a clearly prioritized development backlog. Agree who authorizes hours, how findings are recorded and when the consultant must pause for a decision. Hourly access is particularly useful when an internal team owns delivery but lacks one specialist skill.

Project Based engagement suits an approved outcome with acceptance criteria: a configuration workstream, extension or integration component. Define what is included, what the customer must provide and how changes are assessed. A fixed deliverable does not remove the need for timely business decisions or representative test data.

A Dedicated Resource suits sustained implementation work or an evolving roadmap where priorities change but ongoing capacity is needed. Confirm availability, working-hour overlap, technical review and backup arrangements. The resource may be dedicated without being able to own every discipline. Preserve access to finance, manufacturing or integration reviewers when their knowledge is necessary.

Prepare a brief that produces comparable profiles

State your deployment type, country localization, application version, relevant extensions and current delivery partner arrangements. Identify whether the work concerns a new implementation, improvement, migration or support issue. Describe the first expected deliverable and the person who will accept it.

For teams in the United States, Canada, the United Kingdom or Europe, specify actual meeting windows and language requirements rather than writing only “international experience.” A Germany-based finance team may need German documentation; a US project may need overlap with a particular coast. Those requirements should be assessed against the named resource.

Use a simple selection checklist: relevant process experience, evidence of completed work, communication, availability, review discipline and handover quality. Certificates can support the discussion when verified, but they do not replace a scenario assessment. Compare candidates against the same brief, and reserve a clear decision point after the first agreed piece of work.

• First requirement: one transaction with expected and actual outcomes.
• Named reviewer: who approves process rules and technical changes.
• Initial deliverable: a bounded diagnosis, design or tested change.