Create a record tile

What it does

Writes a Dataverse record from inside a journey. Drop a Create a record tile on the canvas, pick a table, map its fields from static values or journey dynamic content, and the journey creates the record as the contact or lead passes through. Typical use is a phone call or task for a seller when a lead does something worth chasing. It left preview on 11 September 2026.

Key facts

Enabled per environment: Settings > Overview > Feature switches > Journey > Record creation. The old preview toggle was called Lead and opportunity creation (preview); an environment that had it on keeps the feature on.
Works on contact-based and lead-based journeys only. Customer Insights – Data profiles aren't supported.
You can only target tables that have a relationship to contact or lead. Event-planning tables (msevtmgt prefix) are excluded outright.
Two principals must both hold the privileges: the journey publisher's security role, and a dedicated service role called Create Record Role Extensible. If either is missing the privilege, the table simply doesn't appear in the picker.
Required privileges on the target table are Create, Append, AppendTo and Assign, plus AppendTo on any table a configured lookup points at.
The built-in tables — lead, task, opportunity, phone call — are already covered by the service role. Custom tables are not; you add them by hand to both roles at business-unit level or higher.
Marketing Service User Extensible still works, but privileges configured there don't get the improved picker behaviour. Microsoft's guidance is to migrate custom-table privileges onto Create Record Role Extensible.
Ownership options on the tile: contact/lead owner, parent account owner, a named user or team, or a dynamic binding. Unresolvable values fall back to the contact/lead owner.
For leads and opportunities, Dynamics 365 Sales assignment rules take precedence over whatever owner the journey sets.
Optional fields added through + Add optional fields are saved per user, per session — not as part of the journey definition for everyone.
Journey analytics shows created records and lets you open them, and reports failures per run.

When to use / skip

Use it for the follow-up work that used to be a Power Automate flow bolted onto a custom trigger: raise a call activity for a hot lead, open a case off a service signal, create a task for an owner. It's simpler than a flow, it's visible on the canvas, and the analytics tie the record back to the journey that made it.

Skip it when the record needs real business logic — multi-record creation, lookups resolved by query, conditional field logic, error handling with retries. The tile maps fields; it doesn't compute. That's still Power Automate's job.

Configuration decisions

Which service role carries the privileges. Take Create Record Role Extensible on anything new and plan the migration off Marketing Service User Extensible rather than running both indefinitely.
Ownership strategy per record type, and whether Sales assignment rules should be allowed to override it (for leads and opportunities you don't get a choice).
Whether the target is a standard table or a custom one, because a custom one doubles the security-role work and adds it to every environment in the ALM chain.
Which fields are set statically versus dynamically, and what an unresolved dynamic field should mean — it lands as empty, not as an error.

Gotchas

The double-permission model is the whole story here. A missing table in the picker almost never means the table is unsupported; it means one of the two principals lacks Create at business-unit level. Check the service role before you go looking for anything cleverer.
Custom-table privileges are environment-scoped config that no solution carries for you. Get them into the deployment checklist or the journey works in UAT and quietly fails in production.
Publishing validates configuration, not runtime. A journey publishes cleanly and still fails to create records because of a business rule, a plugin, or a required field a customisation added. Test with a sample audience and read the execution results before pointing it at a real segment.
Optional field selections being per-user, per-session catches people out in workshops: two makers looking at the same journey see different field sets.
Sales assignment rules silently overriding the tile's owner is correct behaviour and looks exactly like a bug to whoever configured the owner.

Consultant notes

This lands in scope as "we don't need a flow for that any more", and mostly that's true — but the saving is on the build, not on the governance. You've swapped a flow with an owner and a solution layer for a security-role dependency spread across two roles and every environment. Make sure someone owns that.
The Create Record Role Extensible migration is the bit clients will skip. If an environment has been creating leads through Marketing Service User Extensible since preview, it keeps working, so nobody moves. Then a custom table gets added, doesn't show in the picker, and it takes an afternoon to work out why.
Ask early whether Sales assignment rules are live. Marketing configures a journey to assign leads to a named team, Sales has territory rules doing something else, and the two teams spend a fortnight blaming each other's configuration.
Test the failure path in UAT deliberately: put a required custom field on the target table with no default and watch what the journey does. Clients assume a published journey is a validated journey, and the analytics failure view is the only place the truth shows up.

Worth revisiting when Customer Insights – Data profiles become a supported audience, or if the Create Record Role Extensible migration gets a deadline