Let’s tie the whole course together with one realistic scenario: a simple internal Project Tracking solution — the kind of small, self-contained build that’s a very common first real task for a new D365 CE developer.
The data model
Two custom tables: Project (user/team owned — someone manages it) and Project Task (also user/team owned). A 1:N relationship connects them (one Project has many Project Tasks), set to Parental behavior — deleting a Project should delete its Tasks, since a task can’t meaningfully exist without its project.
Columns
Project gets a Name (primary column), a Status choice column (Not Started / In Progress / Complete), a Start Date and Due Date, and an Owner lookup to the User table. Project Task gets a Name, a Status choice, a Due Date, and the automatic Project lookup created by the relationship.
Forms and views
The Project main form shows its own fields plus a subgrid of related Project Tasks. A Quick Create form for Project Task is enabled so a task can be added without leaving the Project record. The default Active Projects view is trimmed to just Name, Status, Owner, and Due Date — enough to scan quickly.
Business rule
A simple Entity-scoped business rule: if Status is set to “Complete,” automatically set Due Date as read-only (locked) — a record marked complete shouldn’t have its due date edited afterward.
Business Process Flow
A BPF on Project with three stages — Planning, Execution, Review — each with a couple of required steps, giving project owners a visual sense of where each project stands.
Workflow
A background workflow on Project Task: when a task’s Status changes to Complete, check if all sibling tasks under the same Project are also Complete, and if so, update the parent Project’s Status to Complete automatically.
Next: Security & Access — controlling exactly who can see and do what with the data model you just built.