Unify Applications
Logo
Meeting

Meeting

Logo

7 mins READ

Overview

The Meeting block packages an entire meeting lifecycle into a single composable block. It has three distinct phases:

unify-applications-meeting-01-meeting-block.png
unify-applications-meeting-01-meeting-block.png

  1. Lobby — the user sees a camera preview, picks and tests their microphone, speaker and camera, reviews the meeting name and purpose, then clicks Join.

  2. Live meeting — a Copilot conversation running in meeting mode with real-time voice and video, mic/camera/captions controls, and an optional side canvas.

  3. End screen — shown after the user leaves. Displays a configurable message and a button that navigates to a configured URL.

Tip: When to use Meeting: Run a face-to-face style AI session — an interview, a consultation, a patient intake. Give users a proper pre-join experience with device choice and mic testing. For text-first AI chat without the meeting framing, use a Copilot block. For voice interaction without the lobby and end screen, use Copilot Voice.

Note: Meeting wraps a Copilot conversation. Under the hood, the live meeting phase is a Copilot conversation in meeting mode — same AI Agent, Chat Key and Chat Context semantics, including the side canvas and its open/close events. Everything documented for Copilot conversations about resuming, context injection and chat state also applies inside the meeting.

Properties

Content

Property

Type

Default

Description

AI Agent (aiAgentId)

agent reference (bindable)

First available agent

The AI agent that runs the meeting. Bind to change dynamically based on context.

Chat Key (initialChatId)

string (bindable)

—

A key identifying the conversation to open. Binding to an existing key resumes that conversation when the user joins.

Chat Context (runtimeContext)

string (bindable)

—

Context handed to the agent when a new chat is created. Can be plain text, a JSON object or an array. Useful for providing case details, user profile or task context.

Meeting Details

These five text fields control what the user reads in the lobby and on the end screen. All are translatable except the URL.

Field

Default

Where shown

Meeting Name

AI Committee Meeting

Lobby header

Meeting Purpose

Discussing the latest AI trends and how to implement them in the organization

Lobby sub-text below the name

End Meeting Message

You left the meeting.

End screen body

End Meeting Button Text

Return Home

End screen button label

Return Home URL

—

Navigation target for the end-screen button

Warning: Always set Return Home URL. If Return Home URL is empty, clicking the end-screen button does nothing — the user is stuck on the end screen. Set it to a valid page path or external URL.

Slots

Slot

Description

Device Selection

The lobby's microphone, speaker and camera pickers. A new block fills it with three pre-wired Single Select pickers. Empty it to use the built-in picker pills instead, or replace its content with your own layout — your blocks must then switch devices with the Set input/output device for media method.

Add-ons

Add-onDefaultDescription
Device TestingEnabledAdds a lobby section where users play a test sound and check their microphone level before joining. Disable to simplify the lobby for users who don't need device verification.

Appearance

The block fills its container by default (width: 100%, height: 100%). Use the standard styles panel for custom dimensions, visibility conditions, margin, padding, stroke and radius.

Events

EventTrigger
On Open Copilot CanvasThe live meeting's side canvas opens.
On Close Copilot CanvasThe side canvas closes.
On End MeetingThe user leaves the meeting — fires before the end screen is shown.

Methods

Call from any event with the Trigger Component Method action.

MethodParamsEffect
Create New Chat—Starts a fresh conversation with the AI agent. Clears the current chat state.
Go to ChatchatIdSwitches to an existing conversation by its chat ID.
Set input/output device for mediadevice selection payloadChanges the active microphone, speaker or camera. Required when using a custom Device Selection slot.

Exposed State

State keyTypeDescription
{{ id.chatId }}stringThe active conversation ID.
{{ id.voiceMode.isVoiceModeActive }}booleanWhether the live session is running.
{{ id.voiceMode.isMicrophoneEnabled }}booleanMicrophone on/off state.
{{ id.voiceMode.isCameraEnabled }}booleanCamera on/off state.
{{ id.voiceMode.isClosedCaptionsEnabled }}booleanCaptions on/off state.
{{ id.voiceMode.agentState }}stringThe AI agent's connection state.
{{ id.voiceMode.roomDetails }}objectThe joined room's ID and name.
{{ id.voiceMode.availableDevices }}objectDetected microphones, speakers and cameras.
{{ id.voiceMode.selectedDevices }}objectThe currently selected device IDs.

Behavior & Gotchas

Everyone joins muted with camera off

In the lobby, both the microphone and camera start disabled. The user must explicitly switch each on before or during the meeting. There is no setting to start hot (microphone or camera on by default on join).

There is no way back from the end screen

Once the user leaves, the block shows the end screen permanently — the meeting cannot be rejoined from there. The Return Home button navigates to the Return Home URL, so make sure it is set (see the warning under Meeting Details). Test the end screen during development.

The Device Selection slot holds the device pickers

A new Meeting block comes with its Device Selection slot already filled: a Stack holding three Single Select blocks (microphoneSelect, speakerSelect, cameraSelect). Each one lists the devices from {{ id.voiceMode.availableDevices }}, shows the selected device, and calls Set input/output device for media when the user picks another. These are the lobby's device pickers, and you can restyle them. If you empty the slot, the block falls back to its own built-in picker pills. If you replace the slot content with your own blocks, they must call Set input/output device for media themselves.

Device pickers show "Detecting..." until the browser enumerates

Until the browser finishes detecting audio and video devices, the lobby pickers display "Detecting..." and remain disabled. A device category with no devices found stays disabled after detection. Users who deny camera or microphone permission at the OS level will see empty picker lists.

The live meeting is a Copilot conversation underneath

Once joined, the session is a Copilot block in meeting mode — the same Chat Key and Chat Context semantics apply. Use Go to Chat to resume a prior conversation, and bind Chat Context to a data source record so every new chat starts pre-informed. The side canvas and its Open/Close Copilot Canvas events behave identically to the standard Copilot block's canvas.

Block

Relationship

Copilot

The same agent conversation as text-first chat. Meeting wraps it in a lobby and end screen.

Copilot Voice

Voice interaction without the meeting framing — no lobby, no end screen.

Camera

Raw camera capture; Meeting manages its own camera preview independently.

FAQs

How do I let a returning user continue the same meeting conversation?

Bind the Chat Key (initialChatId) property to the stored conversation key from your data source — for example {{ currentCase.meetingChatId }}. When the user joins, the Meeting block opens that conversation thread rather than starting a fresh one. This is the same mechanism used by the Copilot block. If the key is empty, a new conversation is created and a new chatId is generated, which you should save to your record using the On End Meeting event.

Can I pre-populate the agent with context about the user or case?

Yes. Bind the Chat Context (runtimeContext) property to any expression that resolves to a string, object, or array — for example a full case record from a data source. The agent receives this context when the conversation is created, and can reference it throughout the meeting. For a returning user resuming an existing conversation, the context from the original session is already in the conversation history, so runtimeContext mainly benefits fresh conversations.

What's the difference between Meeting and Copilot Voice?

Meeting adds a structured shell around the same underlying voice conversation: a lobby with device selection and testing, a joining flow, and an end screen. Use Meeting when you want the user to have a "joining a call" experience with explicit pre-join setup. Use Copilot Voice when you want a minimal embedded voice interaction without the lobby and end screens — for example, a voice button inside a larger page layout.

Why can't my user get back into the meeting after leaving?

The Meeting block shows the end screen permanently once the user leaves — there is no rejoin path. To let users re-enter a meeting, place the Meeting block on a page the user can navigate back to (for instance, the Return Home URL target), or use a navigation action on the end screen that routes them to a fresh page load of the meeting. A fresh page load resets the block to the lobby.

What if device detection never completes or the user has no microphone listed?

The built-in lobby pickers stay disabled and show "Detecting..." while the browser is enumerating devices, and remain disabled for categories with no devices found. If you need to handle this case, watch {{ meeting1.voiceMode.availableDevices }} and show a warning when it resolves empty. Users who have denied OS-level camera or microphone permission will see empty lists — guide them to the browser/OS permission settings to unblock access.