---
title: "YOOBIC Integration"
description: "Connect AI agents to YOOBIC, a frontline execution platform for retail and hospitality teams. Agents publish campaigns that create missions, assign and validate them across sites, track visits, and export the results."
url: https://flowrunner.ai/integrations/yoobic
date_modified: 2026-08-11T09:36:14-07:00
---

# YOOBIC

[Productivity](https://flowrunner.ai/integrations/category/project-management-productivity)

Connect AI agents to YOOBIC, a frontline execution platform for retail and hospitality teams. Agents publish campaigns that create missions, assign and validate them across sites, track visits, and export the results.

[Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 1 trigger · 48 actions · Session · available

[YOOBIC website](https://yoobic.com/) · [Platform Documentation](https://docs.yoobic.com) · Capability data verified 2026-08-11

1.  An On Record Change event fires on the missions topic when a mission is validated
2.  Get Mission returns the answers array, which List Missions never carries
3.  Agent reads the compliance decision and the non compliance reason recorded by the validating manager
4.  A remediation ticket is opened in the ticketing system with the failed questions and photos attached
5.  Create Mission Comment writes the ticket reference back onto the mission thread
6.  Regional manager receives the failure with the site, the campaign and the evidence in one message
7.  Regional manager decides whether the site gets a republished mission or an escalation

## What This Integration Enables

Frontline execution has a shape that back-office automation does not. The work is done by people standing in stores, on shifts, on a phone, at hundreds of locations at once, and the two hard problems are getting the right task to the right site at the right time and getting what they captured back out fast enough to matter. YOOBIC covers both, and this [connector](https://flowrunner.ai/concepts/connectors) exposes enough of it that a flow can own the whole loop.

Agents drive the mission lifecycle in order: assign an available mission to a user, book it, finish it with typed answers, and record a manager's compliant or not compliant decision with Validate Mission. A failed mission can be republished prefilled with the answers already submitted, so only the flagged parts get redone. They filter and count missions with raw conditions, read the workflow step history of workflow campaigns, read and replace quick task checklists, and post and read the comment thread on a mission. They read campaigns with their full question definitions and publish memo, form and workflow campaigns to an audience. They manage the estate: create, read, update, archive and unarchive sites, and read a site's health score across reactivity, accuracy, compliance and review. They manage people: create, update, archive and unarchive users, send activation reminders, and move users in and out of groups. They schedule and approve visits, assign training plans and read per-learner courses and completed lessons, and push internal communication through chat, the news feed and community posts. For anything beyond the 1000 records a single list call returns, Start Data Export queues an asynchronous job that Get Job Status polls for a download URL.

Several behaviours decide whether a flow works or quietly misfires. Mission answers are only returned by Get Mission, never by List Missions, so a reporting flow that only lists is reporting on empty records. A mission must have an assigned user before it can be booked, so Assign Mission runs before Book Mission. Replace Mission Tasks overwrites the checklist rather than merging, and completing that call sets the mission to finished. Geofilter parameters on Create User and Update User replace rather than extend, so a partial list silently shrinks which sites a person can reach. Archiving, not deletion, is the retirement path for missions, sites and users, and an archived username cannot be reused until that user is restored. And the API still calls sites stores on the wire, so responses carry store\_id and store\_type\_name even though every operation here is named Site.

### Without FlowRunner

**Audit results read in the platform**: Failures are found when a manager opens the dashboard, which is not the same day the store failed

**Photos stranded in the mission**: Evidence stays inside the mission record instead of reaching the ticket that fixes the problem

**Estate changes retyped**: New stores and leavers are entered into the frontline platform separately from the HR and store master systems

### With FlowRunner

**Failures leave the platform on the event**: On Record Change fires on validation, so a non compliant result routes without anyone opening a dashboard

**Evidence travels with the failure**: Get Mission returns the answers array, so the photos and values land in the remediation ticket

**Estate kept in sync by the flow**: Create Site, Update Site, Archive User and Unarchive User run from the upstream systems of record

## Use Case Scenarios

### A failed audit that becomes a ticket the same hour

An On Record Change event fires on the missions topic when a manager validates a compliance audit as not compliant. The agent calls Get Mission to read the answers array, because the list call does not carry it, extracts the failed questions and their photo URLs, and opens a remediation task in [Zendesk](https://flowrunner.ai/integrations/zendesk) or [Jira](https://flowrunner.ai/integrations/jira-issues) with the site, the campaign and the evidence attached. It then writes the ticket reference back with Create Mission Comment so the store team sees the follow-up on the same thread they were working in. The gap between a failure being recorded and somebody owning it closes to minutes.

### The estate and the directory stay true

A store opens, a store closes, an associate joins, an associate leaves. The agent reads the changes from the HR system or a store master list in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) and applies them. Create Site is called with both an address and a latitude and longitude pair so YOOBIC does not have to infer one from the other, and Create User with the correct geofilter. Add Users To Group runs after Get Current User confirms that new group ids carry the tenant prefix, and Archive Site or Archive User handles retirements. Send Activation Reminders chases the new joiners who have never signed in. Nobody maintains the frontline platform as a separate directory.

### Compliance reporting beyond the page limit

Quarter-end reporting needs every finished mission across the estate, which is far more than 1000 records. The agent calls Start Data Export for missions with the period conditions, polls Get Job Status until progress reaches 1, and collects the download URL from the completed job before its expiry date passes. It loads the file into a warehouse table in [BigQuery](https://flowrunner.ai/integrations/bigquery) and joins it against Get Site Health Score readings so compliance can be read per site rather than as a single estate-wide average.

## Human-in-Loop Highlight

Publish Campaign is where an agent should stop, because it is the one operation whose blast radius is a workforce. Publishing creates one mission per targeted site or user and returns the count and the new mission ids. The targeting arithmetic is asymmetric in a way that is easy to get backwards. Sites listed in Site IDs are added to the campaign audience, while users listed in User IDs are intersected with it, so a user outside the audience is silently ignored while an extra site pulls a whole location in. Leaving both empty publishes across the entire campaign audience. There is no unpublish operation in this surface. Retiring a wrong publish means Archive Mission per created mission, and the Valid Until archiving script runs hourly rather than at the stated moment, so the work sits on people's phones in the meantime. So the agent resolves the audience first and hands it over. It reads List Sites and List Campaigns, computes exactly which sites and how many missions the publish would create, and asks the regional operations lead: "Publishing \[campaign\] would create 412 missions across 118 sites, including the 9 sites you added by ID. Valid until \[date\]. Confirm the site list, trim it, or hold." The lead approves and the agent publishes. Reading, exporting, ticketing and syncing run unattended. Putting a task in front of every associate in a region gets a person's name on it.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

48 actions

### Missions

15

-   **List Missions** Retrieves missions, the individual tasks a campaign creates for each site or user. Filter by campaign, site, assigned user, status or compliance, and narrow further with a raw where object using the YOOBIC operators. A single request returns at most 1000 records. The answers recorded against a mission are not returned here.
-   **Get Mission** Retrieves a single mission by its id, including the answers array holding every question and the value the frontline user submitted. Answers are only available through this endpoint, so use it after List Missions whenever the captured form data is needed.
-   **Count Missions** Returns the number of missions matching a set of conditions without transferring the records themselves. Useful for compliance dashboards and for deciding whether a result set needs paging or an asynchronous export.
-   **Update Mission** Applies a partial update to a mission. Use it to write a score, extra scores or a non compliance reason back onto the record, or to overwrite specific answers. Read only fields such as status, store\_id and created\_date are ignored if supplied.
-   **Assign Mission** Assigns an available mission to a specific user. YOOBIC requires a mission to have an assigned user before it can be booked, so run this before Book Mission when driving the lifecycle from a flow.
-   **Unassign Mission** Removes the assigned user from a mission, returning it to the pool of available work for the site. Use it to hand a task back when the original assignee is unavailable.
-   **Book Mission** Books an assigned mission, moving it from available to ongoing. When the mission was republished after a non compliant validation, the response also carries original\_mission\_id, original\_reason\_noncompliant and original\_mission\_answers, which can seed the answers passed to Finish Mission.
-   **Finish Mission** Submits a booked mission together with its answers, moving it to finished. Each answer identifies its question and carries a value matching that question type, from strings and numbers to booleans, photo URLs and arrays.
-   **Validate Mission** Records a manager's validation decision on a finished mission, marking it compliant or not compliant. A non compliant mission can be republished for the frontline user to retake, optionally prefilled with the answers already submitted so only the flagged parts need redoing.
-   **Archive Mission** Archives a mission, setting its status to archived and removing it from the active workload of the site. Archiving is the standard way to retire a mission without deleting the record and its captured answers.
-   **Get Mission Workflow** Retrieves the workflow state and step history of a mission created from a workflow campaign, with the current step under workflowState and every completed step under workflowHistory.
-   **Get Mission Tasks** Retrieves the task checklist of a quick task mission, returned under the todo object. Only missions created from a quick task campaign carry tasks.
-   **Replace Mission Tasks** Replaces the entire task checklist of a quick task mission. The todo object must list every task with its new value, because the API overwrites the checklist rather than merging into it. Completing this call sets the mission status to finished.
-   **List Mission Comments** Retrieves comments attached to missions, the thread frontline users and managers use to discuss a task. Filter by mission or by author. Mission comments are flat, with no replies, threading or reactions.
-   **Create Mission Comment** Posts a comment onto a mission on behalf of a user. Supply either text up to 2000 characters or a photo URL, since a comment carries one or the other and at least one is required.

### Campaigns

3

-   **List Campaigns** Retrieves campaigns, the configurable forms that generate missions for frontline teams, covering audits, checklists, promotions, surveys and health and safety monitoring. Set Active Only to return only live campaigns.
-   **Get Campaign** Retrieves a single campaign by its id, including the full questions array that defines the form frontline users complete, each question carrying its id, type, title, page and question number.
-   **Publish Campaign** Publishes a campaign, creating one mission per targeted site or user and returning the count plus the new mission ids. Only memo, form and workflow campaigns can be published this way. Sites listed in Site IDs are added to the audience while users listed in User IDs are intersected with it. This is the action routed for human sign-off.

### Sites

7

-   **List Sites** Retrieves sites, the physical locations that receive missions. The API and every returned field name still call them stores, so records carry store\_id and store\_type\_name. Filter by site type, external client id or VIP status.
-   **Get Site** Retrieves a single site by its id, including its address, geolocation, contact details, timezone and the properties object driving the Site Activity page layout.
-   **Create Site** Creates a site. The site type must already exist, and the site needs either an address or a latitude and longitude pair. Supplying both is more accurate, because YOOBIC otherwise infers the missing one through Google Maps.
-   **Update Site** Applies a partial update to a site. Only the fields supplied are changed. Read only fields such as country, timezone and created\_date are ignored if supplied.
-   **Get Site Health Score** Retrieves the YOOBIC health score of a site, averaging reactivity, accuracy, compliance and review. Each criterion is returned for today and yesterday, alongside an evolution history whose length is set by Days.
-   **Archive Site** Archives a site, removing it from the active estate while preserving its record and history. Archived sites remain readable through the archived sites export.
-   **Unarchive Site** Restores a previously archived site to the active estate so it can receive missions again.

### Users and Groups

11

-   **List Users** Retrieves users, the people at your company with access to the YOOBIC mobile and web apps. Filter by permission role, primary site or username. Note that client\_ids and store\_type\_names cannot be filtered on.
-   **Get User** Retrieves a single user by id, including their role, groups, primary site, tags, preferred language, app versions and the date they last connected.
-   **Get Current User** Retrieves the service account behind the current connection. The returned tenant value is the company name that must prefix any new group id, so call this first when a flow creates groups.
-   **Create User** Creates a user. The username must be unique across both live and archived users, and every user needs either a password or the SSO flag set. Groups must already exist before a user can be placed in them.
-   **Update User** Applies a partial update to a user. Supplying Site Client IDs or Site Type Names replaces the user geofilter rather than adding to it, so send the complete intended list.
-   **Archive User** Archives a user, revoking their access while preserving the record and their mission history. An archived username cannot be reused for a new account until the user is restored or purged.
-   **Unarchive User** Restores a previously archived user, returning their access to the YOOBIC apps.
-   **Send Activation Reminders** Sends account activation reminder emails to the listed users. YOOBIC only emails users who have never signed in and who have a work email recorded, so users outside that set are silently skipped.
-   **List Groups** Retrieves groups, the structures that organize users and control what shared content they can see. A group id is its title in lowercase with underscores replacing spaces, and groups nest.
-   **Add Users To Group** Adds users to a group, granting them everything shared with that group. The response returns the group with its complete membership after the change.
-   **Remove Users From Group** Removes users from a group, withdrawing their access to content shared with it. The response returns the group with its remaining membership.

### Visits

3

-   **List Visits** Retrieves scheduled site visits. Visits stay pending until a manager approves them by marking them compliant. Filter by the visiting user, the site or the scheduled date.
-   **Create Visit** Schedules a site visit for a user on a given date. Group IDs decide who can see the visit. New visits are pending until validated.
-   **Update Visit** Applies a partial update to a visit. Use it to reschedule, change the visiting user, or record the manager approval by setting Compliant, which moves the visit out of the pending state.

### Learning

3

-   **List Courses** Retrieves courses, the per learner instance created when a plan is assigned to a user. Filter by plan to see who was assigned it and by user to see one person's training record, with assignment, start, due and finished dates plus points earned and minutes spent.
-   **Assign Plan** Assigns a training plan to one or more users, creating a course for each of them. The response is the array of new course ids, in the order the users were supplied.
-   **List Lessons** Retrieves completed lessons, the individual activities learners work through inside a course. Finished lessons carry the answers the learner submitted along with the score and time spent.

### Communication

4

-   **Send Chat Message** Sends a direct message from one YOOBIC user to another inside the app. Both sender and recipient must be YOOBIC users, since chat is internal communication rather than an outbound email or SMS channel.
-   **Create News Post** Publishes a post to the main YOOBIC news feed on behalf of a user. Group IDs control who sees the post. The description supports HTML and images are supplied as an array of URLs.
-   **Create Community Post** Publishes a post to a community on behalf of a user. Choose Publish Now to post immediately, or Schedule For Later together with a publish date.
-   **Create Community Post Comment** Adds a comment to a community post on behalf of a user, so a flow can push replies from an external channel back into the YOOBIC community thread.

### Jobs and Exports

2

-   **Start Data Export** Queues an asynchronous export job for an entity, which is how to retrieve more than the 1000 records a single list call returns. The response carries the job id to poll with Get Job Status. The fields filter is not supported on exports.
-   **Get Job Status** Retrieves the status of an asynchronous job. Progress runs from 0 to 1. A finished export job exposes the file under data.output.data.download\_url together with the expiry date after which the file is no longer available.

## Triggers

1 triggers

### Event Triggers

1

-   **On Record Change** Fires when a record changes in YOOBIC. Pick the topic to watch (missions, sites, users, visits, campaigns, courses and more) and which operations should fire it. The delivered payload carries the action, the topic, the full entity under data, and updatedFields listing what changed. Mission Workflows delivers a mission record with the extra workflow\_step\_title, workflow\_step\_id and workflow\_state fields. Note that mission comments and mission services only emit create and update, and visits never emit delete, since deleted visits arrive on the missions topic instead. Configure the optional Webhook Secret to have YOOBIC sign each delivery, because without it the vendor signs nothing and the callback URL is the only protection.

## Frequently Asked Questions

### What can FlowRunner do with YOOBIC?

FlowRunner agents can run List Missions, Get Mission, and Count Missions in YOOBIC, plus 45 more actions.

### Does connecting YOOBIC to FlowRunner require OAuth?

No. YOOBIC connects to FlowRunner with session-based authentication, no OAuth flow required.

### Can YOOBIC trigger a FlowRunner workflow automatically?

Yes. YOOBIC supports 1 trigger that can start a FlowRunner workflow automatically.

**Work at YOOBIC?** This integration exposes YOOBIC to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current.

---
Markdown version of https://flowrunner.ai/integrations/yoobic. Site index: https://flowrunner.ai/llms.txt
