From Calculated Fields to compiled X++

Workday gives a developer Calculated Fields, Business Process conditions, Studio/EIB transformations and Extend orchestrations — declarative and semi-declarative surfaces over a data model you cannot query directly. D365 F&O gives you a compiled language with direct table access. This module teaches the X++ select family, transactions and the extension model from first principles, anchored against the nearest Workday equivalent of each.

What you will be able to do

• Translate a Calculated Field lookup, a Custom Report filter or an EIB extract into the nearest X++ select statement
• Explain why update_recordset, delete_from and insert_recordset are set-based tools Workday never needed you to have
• Describe ttsbegin/ttscommit/ttsabort reference counting and why it is not the same boundary as a Business Process Final Action
• Account for DataAreaId injection and RecId surrogate keys where a Workday company or Worktag habit does not carry over
• Map each Workday extensibility surface — Calculated Field, BP condition, Studio/EIB, Extend — to its X++ or platform equivalent
• Write a Chain of Command validation on validateWrite that reproduces a Business Process validation condition

Introduction

Chapter 1 of this domain covered the platform: the metadata model, the no-overlayering rule, and where the extensions live. This chapter covers the part that will feel most unfamiliar day to day — the language you write in, and the fact that you are now writing a language at all.

The select family: from Calculated Fields and Custom Reports to embedded SQL

X++ embeds data access directly in the language, the way a Custom Report's data source is declared directly in the report designer — except the X++ version is compiled code, not a configured object, and it can touch any table the AOS exposes rather than only the fields a report definition has chosen to surface.

Transactions: ttsbegin, ttscommit and the end of Business-Process-shaped commits

Start from first principles, because Workday never required you to think about this at all. A database transaction is a unit of work that either writes completely or not at all. X++ marks the boundary explicitly:

The data model underneath: business-object graph, Worktags, company scoping and RecId

Workday's data model is a graph of business object instances, each identified by a WID, connected to other instances through named relationships — a Supplier Invoice Line related to a Spend Category, related to a Supplier, related to Payment Terms. You never see a schema;

Extension surfaces mapped: Calculated Field, Business Process, Studio/EIB and Extend

The row worth dwelling on is the first one, because it is where most Workday developers first meet Chain of Command.

Objects, types and what replaces a Worktag-shaped working set

X++ wraps the data-access statements above in an ordinary object-oriented language. The concepts to learn, in order of how quickly they bite:

Worked translation: the same validation, twice

Requirement: a Supplier Invoice line whose Spend Category Worktag is flagged inactive must not be submittable.

Knowledge check

Summary

X++ is a compiled, SQL-embedded language sitting directly on top of D365's relational tables — a genuinely different kind of surface from anything Workday gave you, and the single biggest adjustment on this whole site. The adjustment is learnable in a fixed number of pieces, not an open-ended one.