A Finding is a durable record that something worth noticing happened — a document is missing required information, a value crossed a threshold, an incoming email matched a pattern you're watching for. Findings are the layer between "something happened in the workspace" and "someone should know" or "something should run."
Where to find this
Open Workflows → App events, or the Findings overlay directly. It has three tabs:
- Findings — the results: every Finding that's been created, filterable by type and severity
- Rules — where you define what should create a Finding
- System log — a raw activity feed
Two ways a Finding gets created
1. Finding Rules — watching document content
A Finding Rule inspects workspace content and creates a Finding when a condition matches. Rules run independently of workflows — they don't need a workflow to exist to be useful. A rule can simply flag something for you to review later in the Findings tab.
When does a rule actually run? Not on a schedule, and not by scanning your whole workspace when you save it. A rule is evaluated automatically the moment an artifact version becomes readable:
- Immediately, for plain-text content (notes, already-readable files)
- The moment background processing finishes, for anything that needs it first (a PDF, a scanned document, an uploaded file being indexed)
This means saving a rule does nothing to your existing files. It only affects documents created or updated from that point forward. If you need to check files that already exist in your workspace, that's a separate action, not something rule creation does automatically.
What can a rule check today. The rule builder currently supports five condition types:
| Condition | What it checks |
|---|---|
| Text contains | The document's text includes a specific phrase |
| Text is missing | The document's text does not include a specific phrase |
| Information is missing | A specific kind of information (email address, date, amount) is absent |
| Field exists | A specific field is present in structured data |
| Field is missing | A specific field is absent from structured data |
A rule's scope decides which files it checks — the whole workspace, a specific folder, a specific artifact type, or a specific file. Getting scope right matters: a rule with no scope narrowing runs against every future readable file in the workspace, not just the ones you had in mind. A rule named "Invoice missing vendor email" only checks for a missing email — it does not also verify the document is an invoice unless its scope is narrowed to where invoices actually live. Read what a rule will actually do before activating it, not just its name.
More condition types exist as finding types but aren't yet authorable from this form — numeric thresholds, outlier detection, content-drift detection, and connector-specific findings (like a Gmail SLA breach) are all real, existing Finding types that can be seen and filtered in the Findings tab and selected as a workflow trigger condition, but the Rules form doesn't yet have a UI to create new ones of those kinds. That gap is actively being worked on.
2. Watches — reacting to connected-app activity
A Watch is a subscription to activity in a connected app — new Gmail messages, new GitHub issues, new files in Drive. A Watch doesn't create a Finding on its own; it decides which app activity Filepad is allowed to notice at all. When a Watch sees matching activity, Filepad normalizes it into a Finding.
Watches are created and managed on their own, separately from any single workflow — the same way Finding Rules are. This is deliberate: a Watch is a reusable "keep an eye on this" subscription, not a one-off setting buried inside a workflow.
How Findings connect to workflows
A workflow can use "Finding detected" as its trigger — meaning the workflow starts automatically whenever a Finding is created that matches conditions you choose:
- A specific Finding Rule — only react to Findings from one rule you've already created
- Finding type — react to any Finding of a certain kind (e.g. any "Field is missing" Finding, regardless of which rule produced it)
- Severity — react only to Info, Warning, or High alert Findings
- A Watch — for app-event triggers specifically, react only when one of your selected Watches records a match
Workflows are a consumer of Findings, not their author. Building workflow logic doesn't require touching Finding Rules, and creating a Finding Rule doesn't require a workflow to exist. You can use Findings purely as a review feed — check the Findings tab periodically — without ever wiring a workflow to them.
A concrete example, end to end:
- Create a Finding Rule scoped to your Invoices folder: "Information is missing → Email address," Warning severity.
- Upload an invoice document to that folder with no vendor email address.
- The moment the upload finishes processing, the rule evaluates the new version, finds no email, and creates a Warning Finding.
- A workflow with a "Finding detected" trigger (matching that rule) starts automatically and sends you a notification.
- You open the Finding, see which document triggered it, add the missing email, and save a new version.
What isn't automatic yet
Editing a document to fix the issue a Finding flagged does not automatically resolve that Finding. A new version may generate a new evaluation, but the lifecycle connection between "the underlying problem was fixed" and "mark the old Finding resolved" isn't handled for you today — treat Findings as a record of what was true at evaluation time, and expect to manage their status directly in the Findings tab.
Next steps
- Writing in Filepad — the editors this content lives in
- Core concepts — workspaces, artifacts, and the object model