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 — don't confuse it with the separate Service Management module, which handles after-sales dispatch and contracts rather than billable project work.

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.

Decision matrix — BC Projects vs Project Operations

Signal	Stay on BC Projects	Move to Project Operations
Billable headcount	Up to a few hundred	Many hundreds or thousands
Sales pipeline integration	Sales team lives in Business Central	Sales team lives in Dynamics 365 Sales / CRM
Resource scheduling	Simple availability + skills lookup	Skill-based scheduling board, utilisation forecasting, subcontracting
Time entry	Occasional, back-office friendly	Mobile-first, weekly cadence, approvals, integrations to HR
Multi-currency, multi-entity	A handful of entities	Corporate PSA with intercompany billing across dozens of entities
Reporting	Financial reports + Power BI cover it	Dedicated PSA analytics, project accounting to F&O

Two or more boxes in the right column point at Project Operations. One box is rarely enough on its own — the BC Projects module is genuinely capable, and moving to PSA is a project in itself.

A worked example: a services firm on BC Projects

A 60-consultant firm on Business Central runs delivery entirely inside the Projects module: a project per engagement, tasks per workstream, planning lines that split budget between billable, non-billable, and expense; time sheets submitted weekly and posted to the project journal; billing on a mix of time-and-material for retainers and fixed-price for statement-of-work engagements. WIP recognises revenue as costs land, and a monthly WIP-to-billing reconciliation sits at the heart of month-end.

The pain points that would push the firm toward Project Operations are all human-scale: resource scheduling by skill and calendar, better mobile time entry, and a sales pipeline in D365 Sales that hands off cleanly into a project. As long as none of those hurt more than the migration would, BC Projects is the right home.

Wrong-fit signals

• Multi-entity, multi-currency intercompany billing across dozens of engagements per month — BC's intercompany is not tuned for PSA volume.
• Complex resource scheduling that needs a schedule board, utilisation forecasts, or subcontracting management — those are Project Operations features, not BC ones.
• Regulatory revenue-recognition needs (ASC 606 stages, percentage-of-completion on long-running fixed-price contracts) that require finer control than WIP recognition offers.

If two or more of those hurt, look at Project Operations; if just one hurts, price the ISV or partner app that closes the gap and revisit in twelve months.