FlowRunner
PricingContact
Theme
Start Free

FaceUp

HR

Connect AI agents to FaceUp, the anonymous whistleblowing and reporting platform. Agents pull aggregate report statistics and run custom GraphQL queries so compliance teams can monitor reporting activity from their workflows.

Verified 2 actions API key available
FaceUp website ↗ Platform Documentation ↗ Capability data verified 2026-08-10
A weekly schedule starts the case load review
Agent runs Get Report Statistics for the period and selects the count metrics it needs
Agent compares open, overdue, and closed counts against the previous period and confirms the filter set still describes a group large enough to report on
The compliance owner receives the aggregate counts and the change since the last period
The compliance owner decides whether anything narrower than the aggregate is needed, and does that work inside FaceUp where the platform's own access controls apply

What This Integration Enables

FaceUp is an anonymous whistleblowing and reporting platform, and this connector is deliberately small. It does two things. Get Report Statistics runs the platform's publicStatistics query and returns aggregate numbers: total, open, archived, closed, and overdue report counts, report counts by month, and change metrics. You can filter that aggregate by date range, status, priority, source, justification, creation origin, closing reason, deadline, tag, and rating, and choose which metrics come back. Run GraphQL Query sends a raw operation to the FaceUp GraphQL API for anything the dedicated action does not cover, and returns the resolved data object.

What the connector does not do is more important than what it does, and it should be stated plainly. It is not a case management surface. There is no action that reads a report's contents, no action that replies to a reporter, and no action that changes a case's status. Reports stay in FaceUp, where the platform's own access controls apply. What crosses into a flow is a count.

That shape is the right one for this category. FlowRunner's own product thesis is that agents should do the work that is genuinely repetitive and stop at the decisions that carry consequences. In a whistleblowing system, almost every decision carries consequences, and the repetitive work is narrow: noticing that the overdue count went up, noticing that nobody has looked at the queue this week, and producing the same quarterly figures without a person retyping them. Automating exactly that and no more is a design choice, not a limitation to apologize for.

FaceUp does support webhooks for report, message, and internal comment events, but they can only be created and managed inside the FaceUp administration interface, and the platform exposes no API for managing their lifecycle. This connector therefore ships no FlowRunner trigger, and flows here start from a schedule. Authentication uses an API key created under Integrations, then API keys, plus a data region header taken from your organization settings. Nothing on this page describes FaceUp or FlowRunner as certifying compliance with any reporting regulation. That question belongs with your counsel, not with an integration page.

Without FlowRunner

Case load reviewed by opening the tool Someone signs into FaceUp when they remember, and the review happens at whatever cadence that produces
Overdue found late A report passes its deadline and nobody notices until the next scheduled review
Board figures assembled by hand Quarterly counts are read off the screen and retyped into a slide

With FlowRunner

Case load reviewed on a schedule Aggregate counts are pulled every week and compared against the previous period automatically
Overdue surfaced as it happens The overdue count is watched between reviews and a rise raises a person
Board figures pulled by query Monthly counts and change metrics come from the same filtered query every quarter

Use Case Scenarios

The Queue Nobody Forgot to Check

Whistleblowing queues are quiet for long stretches, which is exactly why they get neglected. Each week the agent runs Get Report Statistics for the trailing period, selecting open, overdue, and closed counts, and compares them against the previous run. When the numbers are unchanged it says so briefly and stops. When open reports have risen, or when the overdue count has moved at all, it raises the change to the compliance owner through FlowRunner's human-in-the-loop step and the owner opens FaceUp to work the queue. The agent never sees a report. It only ensures that a person looks at the right week.

Deadline Watch Between Reviews

Reports in FaceUp carry deadlines, and the statistics query can filter on the deadline attribute. The agent polls the overdue count between the weekly reviews on a cadence agreed with the compliance owner. A rise triggers an immediate escalation naming only the count and the period, never a case. If the escalation goes unanswered for a set interval, it moves to a second named person. This is a digital andon cord for a process where the failure mode is silence, and it works precisely because a number is enough to raise the alarm.

The Quarterly Pack, Built the Same Way Every Time

Governance reporting asks for the same figures each quarter: reports received, reports closed, average case load by month, and the change against the prior period. The agent runs Get Report Statistics once with a fixed, reviewed filter set and the monthly count and change metrics selected, then assembles the pack. The filter set is version controlled and changed only by a human, which is what makes the numbers comparable quarter over quarter. Where a figure genuinely is not available from the statistics query, Run GraphQL Query can retrieve it with a reviewed operation string, and that string is treated as part of the reviewed configuration rather than as something a flow composes on the fly.

Human-in-Loop Highlight

The gate on this connector is not on a write. It is on narrowing. FaceUp exists so that a person can raise something without being identified, and an aggregate statistic protects that only while it stays aggregate. Filter the same query by one tag, one month, one creation origin, and one closing reason, and the count that comes back can describe exactly one human being. The connector will happily run that query, because it is a valid query. So the agent checks the shape of the request before the result travels: when a filter combination narrows the population below the threshold your compliance owner has set, or when a raw operation is being sent through Run GraphQL Query, it stops and asks. The message names the filters and the destination, not the data: "This quarterly pack query filters to tag Harassment, site Rotterdam, and closing reason Substantiated for a single month, and writes its output to the governance folder. That combination may describe a very small number of reports. Run it, broaden the filters, or keep this breakdown inside FaceUp?" The compliance owner decides. Run GraphQL Query deserves the same treatment for a second reason: it accepts mutations as readily as queries, so the reach of any operation it sends is the reach of the API key behind it. Both cases are the same rule, applied where it counts. The agent may count. Only a person decides when counting becomes identifying.

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

2 actions

Reporting Statistics

1
  • Get Report Statistics Retrieve aggregate whistleblowing report statistics through the `publicStatistics` query. Filter by date range, status, priority, source, justification, creation origin, closing reason, deadline, tag, and rating, then select which metrics to return: total, open, archived, closed, and overdue counts, report counts by month, and change metrics. Used for scheduled case load reviews, deadline watches, and governance reporting.

Direct API Access

1
  • Run GraphQL Query Send a raw GraphQL operation to the FaceUp API and return the resolved data object, with an optional variables object. GraphQL errors are surfaced as a thrown error. This is an escape hatch for operations the dedicated action does not cover, and because it accepts mutations as well as queries, the operation string belongs in reviewed configuration rather than being composed at runtime.

Frequently Asked Questions

What can FlowRunner do with FaceUp?

FlowRunner agents can run Get Report Statistics and Run GraphQL Query in FaceUp.

Does connecting FaceUp to FlowRunner require OAuth?

No. FaceUp connects to FlowRunner with an API key, no OAuth flow required.

Can FaceUp trigger a FlowRunner workflow automatically?

FaceUp doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with FaceUp

$100 in credits. No card required. Connect in minutes.