EAD Factory integration researchA little less busywork with EAD Factory.
Research only. Grunt is prelaunch, live service is paused, and live provider connections and outcomes remain unverified. The operations and examples below are not confirmed live Grunt features or approved supplier commitments.
Explore possible EAD Factory workflows with Grunt. Documented operations include Evidence Manager: Em assign case file relationship; Evidence Manager: Em case file delete bulk; Evidence Manager: Em case file report generate. Actions on this page are research candidates from public integration definitions, not confirmation that Grunt support is live.
Exploratory scope only: these candidates come from public integration definitions and are not confirmed as live Grunt features.
“Explore whether a Grunt integration could em assign case file relationship, then em case file delete bulk in EAD Factory. Show me the result and wait for my approval before changing anything.”
Illustrative steps and outcome; no real work is performed here.
- 01Evidence Manager: Em assign case file relationship
- 02Evidence Manager: Em case file delete bulk
- 03Review the result before anything changes
A clearer next step, with the final say still yours.
Explore possibilities with EAD Factory.
Researched operations, not a list of enabled Grunt actions. Actual support, account permissions, supplier terms, and live acceptance require separate verification.
60 researched capabilities across 3 groups
- Em assign case file relationship
Assigns a relationship on a case file, linking it to an external/related entity reference for traceability. Use after creating the case file when your workflow tracks which matter, client, or system record it belongs to. Requires: evidence_case_file_create → caseFileId.
- Em case file delete bulk
Permanently deletes SEVERAL case files in one call. Destructive and not reversible — confirm the caseFileIds first (evidence_case_file_search) and prefer closing a case file via evidence_case_file_status_update when you only need to end work on it.
- Em case file report generate
Generates the SIGNED evidentiary report of a case file (the certified document covering its sealed evidence). Returns a reportId — then call evidence_case_file_report_pdf_url_get (PDF) or evidence_case_file_report_zip_url_get (full package) to download. Requires: evidence_case_file_create → caseFileId; preview first with evidence_case_file_report_preview.
- Em case file update bulk
Updates the editable metadata of SEVERAL case files in one call (each entry carries its own caseFileId and changes). Prefer evidence_case_file_update for a single case file. Requires: the caseFileIds of every case file to update (evidence_case_file_search to find them).
- Em create case file
Creates a new case file — the top-level container for evidence groups, evidence, and reports. Use this first, before any other Evidence-manager tool. No prerequisites. Unlike most create tools, `ID` is CALLER-SUPPLIED (generate a fresh UUID v4 yourself, this API does not assign one) — there is no `name` field, use `title` instead. Example: evidence_case_file_create({ ID: '<generate a UUID v4>', title: 'Q1 2026 audit' }) — use that same ID as caseFileId in evidence_group_create.
- Em create download url
Creates a temporary download URL for an evidence's stored file when you only hold the evidenceId (no group path needed — same bytes as evidence_group_evidence_download_url_create). Requires: generate_evidence or evidence_group_evidence_register → evidenceId.
- Em create group
Creates an evidence group inside a case file — evidence records are always registered inside a group, never standalone (except via the legacy generate_evidence tool). Use when starting a new batch of related evidence (e.g. all files for one incident). Like evidence_case_file_create, `ID` is CALLER-SUPPLIED (generate a fresh UUID v4 yourself). Requires: evidence_case_file_create → caseFileId. Example: evidence_group_create({ ID: '<generate a UUID v4>', caseFileId, type: 'FILE' }) returns { status: 'OPEN', ... } — use that same ID as evidenceGroupId in evidence_group_evidence_register, then evidence_group_close once every evidence in the group has been uploaded.
- Em create group evidence download url
Creates a temporary download URL for an evidence file stored in a group (INTERNAL custody). Use to retrieve the original bytes after upload. Requires: caseFileId + evidenceGroupId + evidence_group_evidence_register → evidenceId.
- Em create group evidence upload url
Creates a fresh presigned upload URL for an ALREADY-REGISTERED evidence in a group — step 2 of the register-then-upload flow (PUT the file bytes to the returned URL). Use when the URL from evidence_group_evidence_register expired or was lost. Requires: caseFileId + evidenceGroupId + evidenceId. evidence_create_sealed does all of this automatically.
- Em create temp file upload url
Creates a presigned upload URL for a TEMPORARY file not yet registered as evidence. Use for staging content that another operation will reference; for real evidence prefer the register-then-upload flow (evidence_group_evidence_register) or the evidence_create_sealed composite, which handle registration and upload together.
- Em delete evidence
Permanently deletes one evidence by evidenceId (no group path needed). Destructive; sealed content should not be deleted — use only for drafts or mis-registered evidence. Requires: evidence_group_evidence_register or generate_evidence → evidenceId.
- Em delete group evidence
Permanently deletes one evidence from an evidence group. Only makes sense while the group is still OPEN (sealed groups are immutable). Requires: caseFileId + evidenceGroupId + evidence_group_evidence_register → evidenceId.
- Em delete report
Permanently deletes a generated report by its reportId. Destructive — the signed document and its package stop being downloadable. Requires: evidence_case_file_report_generate → reportId. The underlying case file and its evidence are NOT touched.
- Em generate evidence
Register a new evidence (legacy top-level name; not scoped to a specific evidence group at creation time, unlike evidence_group_evidence_register). Use for standalone evidence outside the group-based flow, or for continuity with the legacy EAD-Factory-MCP integration. Requires the file's SHA-256 hash. Prefer evidence_create_sealed for a new, complete evidence group + evidence + seal flow. Custody type: INTERNAL = EAD Factory stores and custodies the file itself. | EXTERNAL = The file lives outside EAD Factory — you attest to its hash only, EAD Factory never stores the bytes. Testimony (qualified proof) provider family: TSP = Trusted Service Provider — eIDAS-qualified electronic timestamp; the legally strongest proof tier. | DLT = Distributed Ledger Technology — blockchain-anchored proof; immutable and independently verifiable.
- Em get case file
Retrieves a case file's details by ID. Use to confirm a case file exists, or to check its status before creating evidence groups or reports under it. Requires: evidence_case_file_create → caseFileId.
- Em get case file report pdf url
Retrieves a download URL for the signed PDF document of a case-file report. Requires: evidence_case_file_report_generate → reportId (plus caseFileId). For the full evidence package (PDF + files + verification data) use evidence_case_file_report_zip_url_get.
- Em get case file report zip url
Retrieves a download URL for the complete ZIP package of a case-file report (signed PDF plus evidence files and verification material). Requires: evidence_case_file_report_generate → reportId (plus caseFileId).
- Em get evidence
Retrieves an evidence record's details and status by ID (legacy top-level name). Use to check an evidence's timestamping status (IN_PROCESS / COMPLETED / ERROR) after registration. Requires: generate_evidence or evidence_group_evidence_register → evidenceId.
- Em get group
Gets one evidence group's details — status (OPEN/CLOSED), seal information, and its evidences with their upload states. Use to verify every file was uploaded before evidence_group_close, or to check the seal after closing. Requires: caseFileId + evidence_group_create → evidenceGroupId.
- Em get group evidence
Gets one evidence's details (metadata, hash, custody, upload state) inside a specific evidence group. Requires: evidence_case_file_create → caseFileId, evidence_group_create → evidenceGroupId, evidence_group_evidence_register → evidenceId.
- Em get report pdf url
Retrieves a download URL for a report's signed PDF when you only hold the reportId (no caseFileId path needed — same document evidence_case_file_report_pdf_url_get returns). Requires: evidence_case_file_report_generate → reportId.
- Em get report zip url
Retrieves a download URL for a report's complete ZIP package when you only hold the reportId (same package evidence_case_file_report_zip_url_get returns). Requires: evidence_case_file_report_generate → reportId.
- Em get thumbnail url
Retrieves a temporary URL for an image evidence's thumbnail at the requested size — use for quick visual verification without downloading the original file. Requires: caseFileId + evidenceGroupId + evidenceId (image-type evidence only) and a thumbnailSize path value.
- Em group close
Seals (closes) an evidence group, triggering qualified timestamping — after this, no more evidence can be added. Use only after every evidence registered in the group has had its file bytes uploaded to the presigned URL from evidence_group_evidence_register. Requires: evidence_group_create → evidenceGroupId, evidence_case_file_create → caseFileId, and the current evidencesCount. ASYNC: the group transitions OPEN → CLOSING → CLOSED; poll evidence_group_get until status is CLOSED before generating a report. Prefer the evidence_create_sealed composite tool for a new group — it registers, uploads, closes, and waits for CLOSED in one call.
- Em group delete bulk
Permanently deletes SEVERAL evidence groups of one case file in one call. Destructive — prefer evidence_group_discard for a single group, and never delete sealed groups that back issued reports. Requires: caseFileId + the evidenceGroupIds to delete (evidence_group_search to find them).
- Em group discard
Discards (deletes) an OPEN evidence group and its registered evidences — use to abandon a group you no longer intend to seal. Destructive; sealed (CLOSED) groups are immutable evidence and should not be discarded. Requires: caseFileId + evidence_group_create → evidenceGroupId.
- Em group evidence register
Register a new evidence in a group — the first step of a 2-step upload (register, then PUT the file bytes to the returned upload URL). Use for each file you want to add to an OPEN evidence group. Requires: evidence_group_create → evidenceGroupId, evidence_case_file_create → caseFileId, and the file's SHA-256 hash (compute it before calling, or use the evidence_create_sealed composite tool which does this for you). Do not call evidence_group_close until every registered evidence's bytes have been uploaded. Custody type: INTERNAL = EAD Factory stores and custodies the file itself. | EXTERNAL = The file lives outside EAD Factory — you attest to its hash only, EAD Factory never stores the bytes. Testimony (qualified proof) provider family: TSP = Trusted Service Provider — eIDAS-qualified electronic timestamp; the legally strongest proof tier. | DLT = Distributed Ledger Technology — blockchain-anchored proof; immutable and independently verifiable.
- Em group update bulk
Updates the editable metadata of SEVERAL evidence groups in one call (each entry carries its own evidenceGroupId and changes). Prefer evidence_group_update for a single group. Requires: the evidenceGroupIds to update (evidence_group_search to find them).
- Em multipart upload start
Starts a MULTIPART upload session for a large evidence file (returns the upload coordinates for uploading the file in parts). Use when a single presigned PUT is not enough for the file size. Requires: an already-registered evidence (evidence_group_evidence_register or generate_evidence → evidenceId) and the file name.
- Em preview case file report
Generates an UNSIGNED preview of a case file's evidentiary report so you can check its content before producing the signed version with evidence_case_file_report_generate. Requires: evidence_case_file_create → caseFileId, with sealed evidence groups inside.
- Em search case file
Searches case files with optional filters (name, status, dates, pagination). Use to find a caseFileId when you don't have it, or to list what exists before creating a new case file with evidence_case_file_create.
- Em search evidence
Searches evidences across the tenant with optional filters (state, dates, pagination) — not scoped to one group. Use to find an evidenceId or audit what exists; for one group's content use evidence_group_get instead.
- Em search group
Searches evidence groups across case files with optional filters (status, dates, pagination). Use to find an evidenceGroupId or list groups pending sealing; for one group's full detail use evidence_group_get.
- Em update bulk
Updates the editable metadata of SEVERAL evidences in one call (each entry carries its own evidenceId and changes). Prefer evidence_update for a single evidence. Requires: the evidenceIds to update (evidence_search to find them).
- Em update case file
Updates a single case file's editable metadata (e.g. name, description). Requires: evidence_case_file_create or evidence_case_file_search → caseFileId. To change its OPEN/CLOSE lifecycle state use evidence_case_file_status_update instead.
- Em update case file report
Updates a previously generated case-file report's metadata. Requires: evidence_case_file_report_generate → reportId (and the caseFileId it belongs to). Does not re-generate the report content — generate a new report for updated evidence.
- Em update case file status
Changes a case file's lifecycle status (OPEN or CLOSE). Use CLOSE when work on the case file is finished and it should no longer accept new evidence groups; reopen with OPEN. Requires: evidence_case_file_create or evidence_case_file_search → caseFileId.
- Em update evidence
Updates a single evidence's editable metadata (e.g. name, description) by evidenceId. The file content and hash are immutable — re-register a new evidence for changed files. Requires: evidence_group_evidence_register or generate_evidence → evidenceId.
- Em update group
Updates an evidence group's editable metadata (e.g. name, description). Only meaningful while the group is OPEN — sealed groups are immutable. Requires: caseFileId + evidence_group_create → evidenceGroupId.
- Em upload url create
Creates a fresh presigned upload URL for an already-registered evidence by evidenceId — step 2 of the register-then-upload flow (PUT the file bytes to the returned URL). Pairs with generate_evidence the way evidence_group_evidence_upload_url_create pairs with evidence_group_evidence_register. Requires: generate_evidence → evidenceId.
Proposed setup considerations
The research notes below describe a possible setup. They are not instructions for an available Grunt connection; actual steps depend on supported operations and provider approval.
- 01
Start with a small, useful task.
Describe a routine step involving EAD Factory. Keep a first version easy to review and change.
- 02
Plan the account access.
Check which EAD Factory account, data, and permissions a safe connection would need. Start with the least access that can do the job.
- 03
Test the details together.
Validate a sample against a disposable account. Confirm which records are read, what could change, and how errors or duplicates are handled.
- 04
Keep the say-so.
Decide which steps could run on their own and which would need your review. Expand access only when the workflow needs it.
RESEARCH NOTES
Questions about the concept.
These notes describe possible uses. Customer availability remains unverified.
What could a Grunt integration do with EAD Factory?
The documented operations include Evidence Manager: Em assign case file relationship; Evidence Manager: Em case file delete bulk; Evidence Manager: Em case file report generate; Evidence Manager: Em case file update bulk. These are research candidates from public integration definitions and need validation and Grunt implementation before they can be treated as supported capabilities.
Could I keep a workflow read-only?
The research candidates do not confirm an implemented EAD Factory connection or a read-only access mode. If built, verify least-privilege scopes and reject writes at the app API boundary.
Will every action run automatically?
If a connection is built, choose which steps could run on their own and which should pause for review. Changes should follow the permissions and approval rules you set.
Do I need to review actions in EAD Factory?
A future integration should let you decide which work could run on its own and which steps need your review.
A little less busywork.
A little more you.
Read the current prelaunch status and confirmed prices.
View pricing status Explore the simulation