# Common Module Flows & Outbound Call Flows

Two additional Architect flow types that complete the flow coverage for Chapter 5.

---

# Common Module Flows

| Section | Description |
|---|---|
| Feature Area | Architect / Flows |
| Flow Type | Common Module |
| Navigation | `Admin → Architect → Flows → Common Module` |
| Primary Function | Build reusable logic once and call it from multiple flows — reduces duplication across flow types |

A common module flow is a reusable container of Architect logic. Instead of rebuilding the same authentication check, language selection, or routing block in every flow, you build it once as a common module and call it from any compatible flow using the **Call Common Module** action.

---

## Study Notes

| Topic | Explanation |
|---|---|
| Common Module | A flow that contains reusable logic callable from other Architect flows |
| Call Common Module action | The action used within a parent flow to invoke a common module — available in **all flow types** |
| Compatible Flow Types | Defined when creating the common module — determines which flow types can call it |
| Snapshot behavior | When a consuming flow publishes, Architect **snapshots the current version** of the common module into that flow |
| Update behavior | Changes to a common module do **not** automatically propagate — consuming flows must be **republished** to pick up changes |
| Older version usage | If you want a consuming flow to stay on an older version, publish the consuming flow *before* updating the common module |
| Size limit | Common module flows have a **lower size limit** than other flow types |
| Input variables | Optional — pass values into the common module from the calling flow |
| Output variables | Returned from the common module back to the calling flow (visible in the right panel) |
| Dependency tracking | Use dependency tracking to view common module version numbers in use |

---

## Compatible Flow Types

When creating a common module, you select which flow types it's compatible with. The available actions inside the common module depend on these selections — flow-specific actions are not shared.

| Flow Type Category | Examples |
|---|---|
| Voice | Inbound Call, Outbound Call, In-Queue Call, Secure Call |
| Digital | Inbound Message, Inbound Email, Inbound Chat |
| Back-office / Automation | Workflow, Workitem |
| Bot | Bot Flow, Digital Bot Flow |

> You can add or remove compatible flow types after creation under `Settings → Common Module Settings`.

---

## Common Module vs Reusable Task (within a flow)

| Attribute | Common Module | Reusable Task (in-flow) |
|---|---|---|
| Scope | Callable from **multiple flows** | Only within a **single flow** |
| Where defined | Separate Common Module flow | Within the flow itself |
| Callable from | Any compatible flow type via Call Common Module action | Only the parent flow |
| Versioning | Snapshot taken at publish time | Part of the parent flow's version |

---

## Call Common Module Action

| Attribute | Detail |
|---|---|
| Available in | All flow types |
| Configuration | Name the action · Select common module flow · Select version (Published or Debug) |
| Input variables | Map values from the calling flow into the common module |
| Output variables | Appear in the calling flow's right panel after the action |
| Version note | Always uses the most recently published version unless you explicitly select an older published version |

---

## Size Limit

Common module flows have a **lower size limit** than other Architect flow types. Monitor the flow size indicator under `Insights & Optimizations → Flow Size` (available at 4 levels: Low / Medium / High / Full).

---

## Use Cases

| Use Case | Example |
|---|---|
| Authentication block | Verify account number → look up in data table → set customer tier variable |
| Language selection menu | Play language options → capture choice → set language variable |
| Business hours check | Evaluate schedule → return open/closed flag |
| Emergency routing check | Check emergency group status → return emergency flag |
| Standard queue transfer | Unified transfer logic used across multiple flows |

---

## Key Takeaways — Common Modules

| Topic | Summary |
|---|---|
| Purpose | Reusable logic across multiple flows — reduces duplication |
| Call action | Call Common Module — available in all flow types |
| Snapshot on publish | Consuming flow snapshots the common module at publish time |
| Must republish to update | Changes don't auto-propagate — consuming flow must be republished |
| Lower size limit | Common modules have stricter size constraints than other flows |
| Compatible flow types | Defined at creation — determines available actions |

---

---

# Outbound Call Flows

| Section | Description |
|---|---|
| Feature Area | Architect / Flows |
| Flow Type | Outbound Call |
| Navigation | `Admin → Architect → Flows → Outbound Calls` |
| Primary Function | Process outbound calls placed by dialing campaigns — handles live answers and voicemails for agentless outbound |
| Key Dependency | Requires a **Contact List** and a **default Wrap-Up Code** before the flow can be created |

Outbound flows process calls that are made without agents — specifically those made by **Outbound Dialing Campaigns**. The campaign's **Call Analysis Response** determines which outbound flow handles a live answer versus a voicemail, so the IVR can behave differently depending on what answered the call.

---

## Study Notes

| Topic | Explanation |
|---|---|
| Outbound Flow | An Architect flow that handles calls placed by an outbound campaign — no agent connected |
| Contact List | Required — must be associated when creating the outbound flow; provides the `call.contact` variable and its properties |
| Default Wrap-Up Code | Required — must be selected at creation; used to tag the interaction if no other wrap-up is set during the flow |
| `call.contact` variable | Automatically available in outbound flows — contains properties from the associated contact list (name, phone, custom fields) |
| Call Analysis Response | Configured in Outbound Dialing — determines which outbound flow receives a **live answer** vs a **voicemail** |
| Agentless use case | The flow handles the entire interaction with no agent handoff — plays a message, collects data, or transfers |
| Flow author vs admin | Flow authors design the routing logic; outbound admins configure which flow runs for a given campaign |

---

## Outbound Flow vs Inbound Flow — Key Differences

| Attribute | Inbound Call Flow | Outbound Call Flow |
|---|---|---|
| Initiator | Inbound customer call | Outbound campaign dials the contact |
| Agent involvement | Routes to agent | No agent — fully automated unless transferred |
| Contact List required | No | **Yes — required at creation** |
| Wrap-Up Code required | No | **Yes — required at creation** |
| `call.contact` variable | Not available | **Automatically available** |
| Assigned via | Call Routing config | Outbound → Call Analysis Responses |

---

## Creation Requirements

Before creating an outbound flow, the following must exist in the org:

| Prerequisite | Why |
|---|---|
| At least one **Contact List** | Required field at flow creation |
| At least one **Wrap-Up Code** | Required default selection at flow creation |

---

## Navigation

| Task | Path |
|---|---|
| Create Outbound Flow | `Admin → Architect → Flows → Outbound Calls → Add` |
| Configure outbound settings within the flow | `Settings → Outbound` (within the flow's configuration page) |
| Assign flow to a campaign | `Admin → Outbound → Campaign Management → Call Analysis Response` |

---

## Configuration Fields (Create Flow Dialog)

| Field | Description | Required |
|---|---|---|
| Name | Unique name for the flow (max 200 characters) | Yes |
| Description | Optional context | No |
| Default Language | Language for TTS in the flow | Yes |
| Division | Division assignment | Yes |
| Contact List | The contact list associated with this flow | **Yes** |
| Default Wrap-Up Code | Wrap-up code applied if no other code is set | **Yes** |

---

## Toolbox Limitations

Some Architect Toolbox actions are **not available** in Outbound Call flows (not displayed in the toolbox). Outbound flows share most features with inbound flows but have certain omissions related to inbound-specific functions (e.g., queue wait, in-queue handling).

---

## Call Analysis Response — Connection to Outbound Flows

The Call Analysis Response (configured in Outbound Dialing) is what connects a campaign to specific outbound flows:

| Call Analysis Result | Action |
|---|---|
| Live Voice Answer | Route to the **live answer outbound flow** |
| Answering Machine / Voicemail | Route to the **voicemail outbound flow** |
| Busy / No Answer | Configure retry behavior |

> This means an organization will typically have **separate outbound flows** for live answers and voicemails within the same campaign.

---

## Key Takeaways — Outbound Call Flows

| Topic | Summary |
|---|---|
| Purpose | Handle agentless outbound campaign calls (live answer + voicemail) |
| Required at creation | Contact List + Default Wrap-Up Code |
| call.contact variable | Auto-available — contains contact list field values |
| Assigned to campaign | Via Outbound → Call Analysis Response |
| Flow author role | Designs the logic; does not specify which campaign uses the flow |
| Outbound admin role | Configures which flow the campaign uses via Call Analysis Response |
| Differs from inbound | No inbound queue routing; contact list required; call.contact available |