When launching HubSpot chat through the chat API / iOS chat SDK, the SDK appears to ignore the requested `chatflow` identifier if the identified user already has an active live chat session. Instead, it always reopens the most recent open conversation, regardless of which chatflow was explicitly triggered.
Why this is a problem
This behavior is confusing and restrictive for organizations that use multiple chatflows for distinct contexts, such as sales, billing, support, or product-specific assistance. In practice, a user may tap a button intended to start a hardware sales conversation and instead be dropped back into an unrelated billing chat that happened earlier.
That creates a poor experience for:
- Users, who are sent into the wrong context.
- Support teams, who lose the ability to route users cleanly by intent.
- Developers, who reasonably expect the SDK to respect the chatflow parameter they provide.
Expected behavior
If a specific chatflow is requested, HubSpot should open that chatflow even when the user has an existing live chat session in another chatflow.
If HubSpot must preserve session continuity for product reasons, then the SDK should at least provide an explicit option or API mode to:
- open a new conversation in the requested chatflow,
- resume the existing conversation,
- or choose between these behaviors programmatically.
Current behavior
The chat SDK accepts a chatflow identifier, but that identifier is effectively ignored whenever the identified user has an open session somewhere in the account. The conversation resumes the latest open chat instead of the requested chatflow.
Impact
This makes it difficult or impossible to build a multi-chatflow experience where chat entry points are context-specific. It also creates ambiguity in the UI and weakens trust, because the user’s chosen action does not match the resulting conversation.
Suggested improvement
Please make the chatflow parameter authoritative when explicitly provided, or add a dedicated parameter that controls whether the SDK should:
- resume any existing open conversation,
- resume only within the specified chatflow,
- or start a fresh conversation in the specified chatflow.
This would make the SDK much more predictable for apps that rely on multiple specialized chatflows.
Example scenario
A customer taps “Ask about hardware sales” from one screen, but because they previously opened a billing chat, the SDK reopens billing instead of hardware sales.
This is surprising and makes the chat entry point feel broken.