Live & anonymous experiences

Some things a site does can't wait for a page reload — pairing two visitors into a video call, showing a live queue position, running a game turn, telling someone their partner just left. MFICore handles all of that the same way: a workflow with a live connection to the visitor's browser.

There is no "chat feature" or "lobby feature" to switch on. You build the experience you want out of the same workflows, datastore tables, variables and pages you already use, and the platform provides the live connection and the pieces that would be unsafe to leave to a page script.

How it fits together

A live connection trigger gives your workflow a long-lived link to a visitor's browser. Your workflow runs once each time the browser sends something, and can push messages back at any moment — including to a different visitor, which is what makes pairing people possible.

A web request trigger is the simpler cousin: the browser (or an outside service) makes one request, your workflow runs, and whatever it produces comes straight back as the answer. Use it for incoming webhooks and for anything that's a plain question and answer.

Both can be set to allow anonymous visitors, so someone with no account can take part.

What you build, and what the platform gives you

You build the logic: who is waiting, who gets paired with whom, what happens on a report. That lives in your workflows, your tables and your pages, so you can change it without waiting for anyone.

How the live part looks is yours too, but it lives somewhere slightly different. You add it to a page as a Live experience block (type / in the page editor), and the page stores just that one line. Its actual markup — the consent gate, the queue, the chat panel — is a template you can open and edit under Content → Control templates. Change it once and every page on the site that uses the block follows.

The platform gives you the parts that need to be trustworthy:

Visitor identity without an account. A "guest" is created for someone who has never signed in, so a report or a block has something to point at.
Blocking. A blocked visitor is recognised by three different signals at once, because blocking only one is the same as blocking none for anyone who clears their cookies.
Video rooms. If your site has a media server, a workflow can create a room and hand each participant a pass that works for that room and no other.
Automatic screening. A workflow can take a still frame from a live room and have an AI model judge it, so you can act on something before a person has to look at it.
Groups, not just pairs. A visitor can ask to be put with up to three other people, and the block shows one video panel each. Each panel gets its own Report button, so a report says which person it means — with three strangers on screen, "Report" on its own doesn't.

Setting one up

Add a workflow and set its trigger to the live connection type. Give it a short name — that name becomes part of the address your page connects to.
Choose who may connect: anyone, signed-in users only, or members of your site.
Build the graph. It runs three ways — when someone connects, each time they send something, and when they disconnect — so start with a Switch on which of those just happened.
Put the matching block on a page, publish, and open it.

Keep it small. A live experience has several kinds of message, and putting them all on one canvas gets unmanageable quickly. The shape that works: work out who the visitor is and whether they're banned, once, at the top; then a Switch that hands each kind of message to its own workflow with a Call workflow step. Each handler is then a small canvas you can open and test on its own, and any cleanup shared between "they disconnected", "they pressed next" and "they pressed stop" is written once. See Workflows & automation → Splitting a big workflow up.

If you want video, buy a media server for the site first. Without one your workflow still runs and visitors are still paired, but the call carries no picture or sound at all — and from the outside that looks exactly like a broken camera. Check for it in your graph and tell the visitor plainly.

Starting from a template

You don't have to start from nothing. Import / Export includes ready-made templates, and the random video chat one brings the whole thing — the pages, the queue table, the workflows, the contact and appeal forms, and a moderation view. Import it, work through the setup checklist it shows you, and change whatever you like.

Every template of this kind ships with placeholder legal pages. Replace them before you let anyone in. An anonymous service carries real obligations — an over-18 agreement, a process for detecting and reporting child sexual abuse material including reporting to NCMEC, a way for law enforcement to reach you, and a retention policy — and no template can make those decisions for you.

Things worth knowing before you rely on it

Blocks raise the cost of coming back; they don't prevent it. Someone determined enough will return. Say so honestly wherever you tell a visitor they've been blocked.

Keep the traffic light. Your workflow runs once per message, and each run is billable. That's fine for the handful of messages a session actually needs — joining, being paired, moving on, reporting. It is not fine for chatter sent many times a second.

Text sent directly between two browsers can't be screened. If you need to be able to see what people say to each other, route it through your workflow rather than peer-to-peer.

A dropped connection is normal. Phones change networks and laptops sleep. Treat the disconnect event and a periodic tidy-up workflow as the real cleanup, not an edge case.

Groups take longer to fill, so don't insist on them. A group of four needs three other people waiting at the same moment. On a quiet site that never happens, and a visitor who asked for a group sits in a queue that looks broken. Have your workflow wait a little, then pair them with whoever is actually there — that is what the block tells them it will do.

Where to look when something's wrong

Run history shows every message as its own run, with what came in and what your graph did. If pairing isn't happening, that's the first place to look — usually the queue table says two people are waiting and the graph never claimed them.

If nobody can connect at all, check the workflow is enabled and its visibility actually allows the people you're expecting.