Skip to main content

Objective Collections

An objective collection is a reusable group of objectives and the wiring between them. Link the collection to several flows when each flow needs the same questions, data lookups, computed values, or human-agent steps.

Unlike a single objective imported from the Objective Library, a collection keeps its internal parent conditions and transitions together. It is also live-linked: when you edit the library collection, every flow that still links to it uses the updated definition without requiring you to edit each flow.

Use a collection for a repeatable block such as:

  • alternate phone number, landmark, and delivery instructions;
  • return reason, product photos, and condition checks;
  • identity details followed by a manual verification child ticket;
  • a reusable qualification questionnaire with its own branches.

Use ordinary task objectives for one-off behavior. Use Detach when you want to start from a collection but customize one flow independently.

What a collection keeps together​

A collection can contain:

  • one or more objectives;
  • parent conditions whose source and target objectives are both in the collection;
  • computed-objective dependencies that stay inside the collection;
  • WhatsApp Flow prefill mappings that use another member of the collection;
  • transitions based on collection objectives, including early completion or an additional reply.

The collection must be self-contained. It cannot refer directly to objectives in a particular flow, contain another linked collection, or transition to another flow. This keeps one library definition safe to reuse in different contexts.

Objective params are not renamed or prefixed when a collection is linked. For example, a member named alternate_phone remains alternate_phone in every linked flow. A flow cannot link the same collection twice, and no two linked or flow-owned objectives may use the same param.

Collections containing a WhatsApp Flow form​

A collection can keep a Flow form objective together with the objectives that supply its prefilled fields. For example, a reusable customer-details collection can contain customerPhone, customerEmail, and form, with mappings from the first two objectives into fields on form.

Every sourceObjectiveParam used by a Flow prefill mapping must name a member of the same collection. Keep source objectives before the form objective so their values are available when WhatsApp renders the form. The linked collection is expanded into ordinary objectives at runtime, so prefill resolution behaves exactly as it does for flow-owned objectives.

If a source value is missing, inactive, null, or blank, only that form field remains empty; the form can still be sent. The Flow itself must have prefill-ready fields and must be republished after enabling prefill support. See Prefilling form fields for the full setup and runtime behavior.

Flow form channel rules are retained inside the collection. They currently run only for WhatsApp customer interactions and are skipped during manual ticket creation and unsupported channels. The remaining eligible collection or host-flow objectives continue normally.

Create a collection​

Objective collections are managed in the Copilot's Library tab.

  1. Create or update a draft flow containing the reusable objectives and their internal branching.
  2. Open Copilot → Library and choose Create collection.
  3. Enter a name and description, then select the draft flow.
  4. Select the objectives that belong in the collection.
  5. Review the objectives and included wiring, then choose Create collection.

When you create a collection from a draft, a parent condition is included only when all objectives it references are selected. Cross-flow transitions are excluded. If a selected objective depends on an unselected objective, include the dependency too or simplify the draft before creating the collection.

You can later edit the collection's name, description, member params, types, and descriptions from the same Library tab. Removing a member also removes wiring that depends on that member so the collection remains valid.

Sample prompts for preparing the source flow​

Copilot can prepare the flow that you use as the collection source. Creating and linking the collection itself is currently completed with the Library and flow-editor controls described on this page.

"In the delivery reschedule flow, add a reusable contact-details block that collects alternate_phone, delivery_landmark, and delivery_instructions. Ask the questions one at a time and require all three."

"Update the returns flow with return_reason, item_opened, and damage_photos. Only request damage_photos when return_reason is damaged."

"Create a verification flow with verification_type, verification_document, and a human-agent objective named manual_verification. Only create the child ticket after the document has a valid value, and route it to the verification team."

"Review the objectives and conditions in the address-change flow. Tell me which objectives form a self-contained block that could be reused without referring to another flow. Do not change anything."

For a Flow form with supporting contact objectives:

"In the <SOURCE FLOW> flow, prepare customerPhone, customerEmail, and form as a self-contained reusable block. Preserve their exact params, order, ask instructions, required and parent conditions, internal transitions, published Flow ID, Flow prefill mappings, enabled channels, and legacy-message setting. Ensure every prefill source used by form is included and appears before form. Do not rename params or change unrelated objectives, completion, handoff, assignment, or ticket behavior. Report any dependency that cannot be included instead of silently removing it."

After reviewing the Copilot's changes, select the relevant objectives in Library → Create collection.

When creating the collection from that draft, select all three objectives. Then link the collection to the source and destination flows and remove the old task-local copies only after confirming the expanded flow has no duplicate params. Collection creation and linking are currently completed with the Library and flow-editor controls rather than a single Copilot migration prompt.

  1. Open Workflows → Flows and edit the destination flow.
  2. In Objectives, choose Link Collection.
  3. Select an available collection.
  4. Optionally enable Gate collection entry on a task objective and configure the entry condition.
  5. Confirm the link and save the flow.

Linked objectives appear as a read-only group in the flow editor. Their internal conditions and transitions come from the library, so edit the collection when the change should apply everywhere.

Gate a collection with an entry condition​

An entry condition is the one supported connection from the host flow into a collection. It applies the same condition to every root objective in the collection.

For example, a flow can collect needs_delivery_help itself, then enter the Delivery details collection only when that value equals yes.

The source must be an objective owned by the host flow, not a member of this or another linked collection. Operators include equals, notEquals, contains, notContains, regex, gt, lt, in, exists, hasValidValue, and apiFailed. For in, enter comma-separated values such as damaged, incomplete, wrong_item.

If you rename or delete the host objective, the flow editor updates or removes its collection entry-condition reference. Review the collection gate before saving when you make either change.

How linked objective values are collected​

A linked objective runs like an ordinary flow objective. It can ask the customer, infer a value, read a data point, execute an action, calculate a value, or create a human-agent child ticket. Each result is stored on the ticket under the member's objective param, so linked values appear in the ticket's objective form alongside flow-owned values.

For example, if a collection contains alternate_phone and delivery_landmark, those are the keys used to collect and retrieve their values. The collection link does not produce a separate combined value.

Flowcall also keeps the library collection and stable member identity as provenance for linked values. This allows collection objectives to remain virtual—rather than being copied into every flow—while their ticket values are still stored and shown normally.

Treat member params as a data contract. Renaming a param updates every currently linked flow, so also review any integration input mapping, computed dependency, report, or external process that refers to the old param. Historical values remain attached to their original tickets.

Human-agent members preserve the normal child-ticket lifecycle: the child is the actionable ticket while its parent waits, and submitting the child objective continues the parent flow.

ActionResult
EditChange the library collection. All flows that remain linked use the new version automatically.
DetachRemove the live reference but keep the collection's current objectives and wiring as editable copies in this flow. Future edits do not propagate.
UnlinkRemove the reference and all objectives, conditions, and transitions supplied by that collection from this flow. The library item remains.

Save the flow after detaching or unlinking.

Safeguards and troubleshooting​

  • Param conflict: rename the conflicting flow objective or collection member before linking. Params must be unique across the whole expanded flow.
  • Incomplete selection: include every objective referenced by a selected condition, computed dependency, or Flow prefill mapping.
  • Collection cannot be deleted: unlink it from every flow first. A collection that has already collected historical ticket values is retained for data integrity and cannot be deleted.
  • Need one customized version: detach the collection in that flow, then edit the copied objectives.
  • Need different entry rules in different flows: keep the collection internal logic shared and configure a different entry condition on each link.