What "Draft-Enabled" Means for the User
A draft-enabled app lets users edit without committing. Open an object, change some fields, and nothing is saved to the active record until you press Save. Close the browser halfway through and your work is still there when you come back.
This is the behavior users expect from modern apps — think of an email draft. Fiori Elements gives you this entire pattern for free once the backend exposes draft support. No custom controller code, no manual state handling.
Active vs. Draft: Two Versions of the Truth
Every draft-enabled entity has two states. The active version is the committed record everyone sees. The draft version is your private working copy, visible only to you.
When you start editing, the framework creates the draft behind the scenes. Other users keep seeing the active version untouched. Only when you save does the draft replace the active version. This is what makes concurrent editing safe without locks.
Key takeaway: draft handling is optimistic concurrency done right. Users never block each other, and nobody loses work to a locked record.
What the UI Does Automatically
The moment an entity is draft-enabled, the object page changes behavior. The Edit button creates a draft and switches the page into edit mode. Save validates and activates; Cancel discards the draft.
Several things come along for free:
- Draft indicator: a banner shows the record has unsaved changes, with who is editing it.
- My drafts: the list report can show a "My Drafts" filter so users find their unfinished work.
- Validation on save: side effects and validations run during activation, and errors land on the right fields.
- Discard on navigation: leaving without saving offers to keep or discard the draft — no silent data loss.
How the App Knows: The Draft Annotations
The UI discovers draft support through OData annotations on the entity — specifically the draft capabilities in the service metadata. As an app developer, you do not wire any of this up. If the backend publishes draft support, the Fiori Elements runtime picks it up and switches the floorplans into draft mode.
This is worth stating plainly because it surprises people: there is no "enable draft" switch in the UI project. The backend contract decides. Your job is to make sure the annotations for editing — which fields are editable, which need value helps — are correct, because draft mode exposes every gap in them.
Side Effects and Field Control
Draft apps lean heavily on side effects. Change a product and the price recalculates; change a quantity and the totals update. These are declared as side effect annotations, and the UI re-reads the affected fields automatically after each change.
Field control annotations decide per-field behavior: read-only, mandatory, or hidden depending on state. Say the status field should lock once the order is released — that is a field control annotation, and draft mode respects it field by field.
Draft mode is a magnifying glass for annotation quality. Every missing value help, wrong field control, or absent side effect becomes visible the moment users start editing. Budget time for an annotation review pass.
When Not to Use Drafts
Drafts add a backend concept — draft tables, activation logic — so they are not free on the service side. For simple entities edited rarely and by one person at a time, direct editing is simpler and perfectly fine.
Reach for drafts when edits are long, multi-step, or collaborative: order entry, master data maintenance, anything where losing half-finished work would hurt. That is exactly the scenario Fiori Elements optimizes for.
Do your Fiori apps use draft mode, or do you stick with direct editing? Share your experience in the comments.