Which record sets should I request to seed an intake environment?
A checklist of the record sets that let a seeded environment run an episode end to end, from cases and parties to scripted events and a transition table.
When you request an intake environment seed, list the record sets you need so the sample is complete enough to run an episode end to end.
- Case records with request type, channel, received timestamp, status, owner and queue, including cases that start in awkward states - Party records with roles and identifiers, plus near-duplicates and conflicting details that test matching behaviour - Document records linked to cases, with type, page count, quality flags and arrival times that differ from the case date - Policy rules covering required fields, required documents, routing conditions and written exceptions for each request type - Task and reminder records that create obligations, such as information requests awaiting a response - Audit events recording actor, action and before-and-after values, so graders can trace what changed - Scripted events such as late uploads, withdrawals and replies that the environment releases at set steps - A transition table listing which status changes are allowed, so invalid actions are rejected consistently
Requesting the full set up front avoids a sample that loads but cannot be run or graded.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- How would a task pack encode a duplicate connection request?
- What should a generated intake release specify?
- What formats and keys can a generated intake release use?
- Can a task pack include policies and environment state as well as records?
- What records can MirrorFirm generate for an intake workflow?
- What could MirrorFirm generate for an intake environment?