Add-on output should live in the core tool when that tool remains the source of truth. The add-on may create a draft or intermediate value, but the accepted result should be stored or confirmed in the core tool rather than left as the only final copy in a separate workspace.
The practical test is whether the add-on can pass its output into the existing workflow, where the receiving record remains identifiable and authoritative.
How to check the integration
-
Identify the authoritative destination. Before testing, the team should name the exact core record or workflow step that will own the accepted output. Anything outside it should be treated as a draft, intermediate value, or reference copy.
-
Test the downstream handoff. The cited custom-prompt documentation states that prompt output can be used in downstream flow actions. The team should verify that the add-on passes a usable result into the intended core workflow and that the receiving step has a defined place for it. This capability alone does not prove that the result will be written back to the core record; that behavior must be confirmed in the actual configuration.
-
Check the review gate. The cited approvals documentation says that a flow starts and then waits for the approvers’ response before the run completes. The team should confirm whether add-on output requires this wait, who may respond, and what event counts as acceptance before the result becomes authoritative.
-
Locate the final copy. After an accepted run, the team should be able to identify one authoritative location for the result. If the add-on still holds the only final copy, the core tool has not remained the source of truth in practice.
What the team must still confirm
The cited descriptions do not establish the following details for a particular setup:
- The exact record, field, or workflow action that will store accepted output.
- Whether the add-on retains independent copies after the handoff.
- Who can view, edit, and approve the output.
- Whether rejection, failure, retry, or interruption can create duplicate or partial records.
- Whether the receiving action records enough context to trace the output back to its originating run.
- Whether the actual permissions and workflow configuration match the documented behavior.
The defensible rule is straightforward: the core tool owns the accepted record, while the add-on generates, checks, or routes the result. Every accepted handoff should end in the core system; if the team cannot identify that destination, the integration boundary is not yet complete.