Furries PH Docs
Dashboard
Event Planning System docs

Workflows

Link Planning and EMS Without Double Entry

How a plan and an EMS event share one identity, catalog, command path, and attendee-publication boundary.

First created Last updated

event-planningemsregocanonical-data

Link an existing EMS event while creating the plan, or use the authorized link endpoint later. The event must belong to the same partner. A project can be linked once; correcting the wrong identity requires support review because changing it could detach audit history from attendee data.

Step 2 — Read the canonical catalog

The workspace reads these EMS records directly:

  • event basics and dates;
  • registration tiers;
  • inclusions and add-ons;
  • tier/inclusion relationships;
  • Event Shop configuration, categories, and listings.

There is no Planning version of these records. EPS stores only links from requirements, tasks, evidence, risks, or approvals to their canonical IDs.

Step 3 — Attach planning work

When creating a requirement, choose a canonical EMS record. The requirement remains a planning record; the tier, inclusion, add-on, or listing remains EMS truth. Completing the requirement does not publish or mutate the EMS record.

Step 4 — Choose a change path

Use a direct canonical command for an authorized low-risk edit. EPS writes a change set with the submitter as reviewer, applies it atomically, and records the reason and idempotency key.

Use an approval-controlled proposal when another person must review. A proposal remains organizer-only through draft, submitted, approved, rejected, or conflicted. Only applied changes canonical EMS data.

Step 5 — Resolve conflicts

Each command may carry the expected event or resource updatedAt. If current EMS data differs, application returns VERSION_CONFLICT. Reload the current values, compare the impact, revise the patch, obtain review again, and apply with a new idempotency key. Never suppress the conflict by blindly dropping expected versions.

Step 6 — Verify publication

The apply function writes canonical records and marks the change set applied in one transaction. After a non-replayed apply, the API schedules the normal Rego data-silo and deployment refresh once. Replaying the same idempotency key returns the recorded result and does not schedule a duplicate refresh.

Verify in this order:

  1. Planning catalog shows the applied value.
  2. EMS shows the same canonical ID and value.
  3. Rego shows only the applied public configuration after publication finishes.
  4. A pending or rejected proposal remains absent from attendee output.

Stop and escalate

Stop for version conflict, unexpected attendee impact, a record belonging to another event, publication failure, or any response containing planning-only fields. Rego clients defensively reject organizer planning keys.

Completion check

An operator can edit an inclusion in EPS and see it in EMS without copying it, and can edit it in EMS and see the update in EPS without importing or synchronizing anything.

All docs