dataverse-create-records

name	dataverse-create-records
description	Create (seed) records in Dataverse tables via the Web API, reusing the Power Apps Code Apps sign-in. Handles choice integers, lookups via @odata.bind, and de-duplication. Use when asked to "seed a Dataverse table", "insert/create Dataverse records", or load data from a seed spec.
metadata	{"author":"chuckytesla","version":"1.0.0","argument-hint":"<data.json|data.yaml> [--dry-run]"}

Create Dataverse records

Generic engine: you feed it a data file (JSON or YAML) and it creates those records in Dataverse, by POSTing to the Web API entity sets. The skill contains no data of its own — the records are always the file you pass. Idempotent when dedupeBy is set — a row that already matches is skipped, so re-running does not duplicate data.

Authentication (reused, no extra sign-in)

Same sign-in as Power Apps Code Apps. The shared helper ../lib/dataverse-client.mjs acquires a Dataverse token silently from the npx power-apps login cache. See the scaffold skill for details. Writing records needs only create privilege on the target table (a maker/user role is enough — admin not required).

Prerequisites

1. The target tables already exist (see the dataverse-scaffold-tables skill).
2. Signed in: npx power-apps login.
3. DATAVERSE_URL set in .env (the environment's Environment URL).

How to run

# preview — NO writes:
node .agents/skills/dataverse-create-records/seed.mjs path/to/data.yaml --dry-run

# insert for real:
node .agents/skills/dataverse-create-records/seed.mjs path/to/data.yaml

The data file is .json or .yaml — see the contract below. Run --dry-run first.

Data contract

One block, or an array of blocks. YAML shown; JSON works identically.

entitySet: myorg_widgets       # OData entity set (plural)
dedupeBy: [myorg_name]         # optional; skip a row if one already matches these columns
records:
  - myorg_name: Example
    myorg_status: 2            # choice columns use the INTEGER value, not the label
    myorg_starttime: "2026-07-02T10:15:00+02:00"

Lookups

Bind a lookup either directly on the record:

- myorg_status: 2
  "[e-mail]": "/myorg_widgets(00000000-0000-0000-0000-000000000000)"

…or resolve the parent by matching columns (the script looks up the GUID for you):

- myorg_status: 2
  $bind:
    myorg_WidgetId: { entitySet: myorg_widgets, match: { myorg_name: Example } }

$bind requires the match to resolve to exactly one row, or it errors for that record.

Authoring a data file from a Markdown spec

If your source is a narrative seed spec (e.g. a specs/*.md), map each row to a record object — choice columns become their integer value, timestamps stay ISO-8601 with offset, and set dedupeBy to a stable key (e.g. the primary-name column) so re-runs are safe. Feed that file to the skill.

Notes

• Choice/picklist values are integers (eppc_track: 4), never the label string.
• dedupeBy on a string column (the primary name) is the most reliable; datetime and number columns also work. Without dedupeBy, every run inserts new rows.
• Failures are reported per-record and the run continues; the process exits non-zero if any record failed.