Jobs vs Projects in Business Central

In wave 2 of 2023, Microsoft renamed the Jobs module in Business Central to Projects. The change is mostly cosmetic, but it ripples through training materials, extensions, reports, and the institutional vocabulary of any partner or customer that has run BC (or NAV) since the early 2000s. If you read older documentation, the terminology can be confusing.

What changed.

• UI labels. "Jobs" became "Projects" in the role centre, navigation, list pages, card pages, and document captions. "Job journal" became "Project journal", "Job planning lines" became "Project planning lines", and so on.
• Reports and Power BI content were updated to reference the new captions.
• Permission sets were renamed in the base permission catalogue.

What didn't change.

• AL object names. The underlying table is still Job (table 167). Job Task, Job Ledger Entry, Job Planning Line — all retained their Job prefix. This is intentional: renaming objects breaks every dependent extension on AppSource. Microsoft chose UX consistency over schema consistency.
• API endpoints. Most BC APIs that surface jobs still use jobs in the URL.
• PowerShell cmdlets that reference jobs.

The consequence. A developer reads "Projects" in the UI but writes Rec.Job No. in code. Training materials need to bridge both vocabularies. Reports built with field captions inherit "Project" labels; reports built with hard-coded text need updating.

Why the rename. Two reasons:

• Brand alignment with Project Operations in the wider Dynamics 365 family. Customers comparing BC's Project module to D365 Project Operations were confused by the "Jobs" name.
• Industry vocabulary. Outside of construction and field service, "Job" is uncommon as a term for billable engagements. "Project" is more universal.

What "Projects" in BC actually does.

• Project planning — task breakdown, planning lines (budget vs billable), schedule.
• Time and expense capture — via the project journal or the user's time sheet.
• WIP — work-in-progress recognition; cost recognised separately from billing.
• Billing — fixed-price, time-and-material, or milestone, via sales invoices linked to project tasks.
• Job costing — actual costs vs budgeted vs billable, by task.

Projects in BC sit between the simplicity of sales orders and the complexity of Project Operations in F&O. For service businesses with a few hundred billable people and straightforward project structures, BC's Projects module is often sufficient.

Localisation and translation. The rename was rolled out language by language. Some translations took longer to land than English — be aware that older non-English BC tenants may still show "Jobs".

Extensions. Apps on AppSource generally followed Microsoft's lead: captions updated, object names untouched. If you maintain an extension that touches the Jobs/Projects domain, your captions should align — but your code remains valid.

Reports and dashboards. A Power BI report that pulled job data via the BC API and named visuals "Job profitability" still works, but the visuals now read incorrectly. Periodic UX hygiene cleans these up.

Operational impact. Users who've been on NAV/BC for years take a few weeks to switch vocabularies; new users only ever see "Projects". The biggest pain point is documentation — training decks, runbooks, and internal wikis still saying "Job number" need updating.

Looking ahead. Microsoft has signalled further alignment between BC Projects and D365 Project Operations, but a single shared engine is not on the public roadmap. For now, the two products remain distinct: BC Projects for mid-market service organisations, Project Operations for larger or more complex engagements. The "Jobs → Projects" rename was a vocabulary harmonisation, not a product convergence.