Skip to content
Open Ontology
Open OntologyPlatform studiesZapier

Zapier, as a program

Your Zaps.
In code.
In context.

Your automation connects your tools.
Its configuration should connect, too.

A Salesforce opportunity. A Stripe customer. A Slack channel. Describe the workflow in one reviewable file, with explicit references to the systems it connects.

Design study · Proposed prelude · No live connections

closed-won.zap.formaWORKFLOW / 001
01 / Trigger · SalesforceOpportunity updatedsales.Opportunity
opportunity
02 / FilterStage is Closed Wonopportunity.StageName
continue when true
03 / Action · StripeFind a customeropportunity.AccountId
customer
04 / Action · SlackTell the sales teamworkspace.channels.sales
Three platforms. One connected definition.Illustrative workflow

01 Write the workflow

02 Check the connections

03 Review the change

01 / The workflow

A Zap is already a program.
Give it a source file.

Triggers start it. Filters decide. Actions pass data to the next system. A proposed Zapier prelude would give those familiar concepts a small, declarative vocabulary.

closed-won.zap.formaProposed syntax
; Bring the connected systems into scope.
(import "@acme/sales" :as sales)
(import "@acme/billing" :as billing)
(import "@acme/workspace" :as workspace)

(zap closed-won "Welcome a new customer"
  (trigger opportunity
    (salesforce/updated sales.Opportunity))

  (filter (= opportunity.StageName "Closed Won"))

  (action customer
    (stripe/find-customer billing.account
      :salesforce-account opportunity.AccountId))

  (action notify
    (slack/send-message workspace.channels.sales
      :text (str "New customer: " customer.name))))
Forma / Zapier prelude conceptImplementation status ↗
Import the real context

References with a home.

The sales model owns the opportunity. Billing owns the customer lookup. The workspace owns the channel. The workflow refers to those definitions.

Follow the data

Every step has a name.

opportunity feeds the filter and customer lookup. customer feeds the message. The data dependencies are visible in the source.

Keep the platform vocabulary

Still a Zap.

The proposal describes a Zapier workflow in Zapier’s terms. A future adapter would need to map these declarations to supported platform resources.

This source is a language design sketch. The imports, Zapier forms, and platform adapters shown here are proposed and cannot be executed by the current package.

02 / The connections

The lines between your apps
are part of the model.

A field mapping is a dependency. A channel is a reference. Open Ontology’s direction is to make these connections part of one checked program, across platform boundaries.

@acme/automations

closed-won

The workflow that connects them.

Salesforcesales.Opportunity.AccountIdField reference
Stripebilling.accountLookup contract
Slackworkspace.channels.salesChannel reference
Shared definitions

Define it where it belongs.

Keep platform configuration in its own project. Let workflows import the definitions they depend on.

Visible dependencies

See what a rename touches.

A future cross-project checker could point from a changed field to the workflows that still reference it.

Agent-readable context

Give agents the whole picture.

Source files can describe the workflow, its inputs, and its dependencies together in a repository.

03 / The change

Small edit.
Visible consequences.

The review should show what changes and which connections need attention. These static examples illustrate the feedback a future checker could provide.

Pull request / closed-wonIllustrative review

(slack/send-message

− workspace.channels.sales

+ workspace.channels.customer-success

:text (str "New customer: " customer.name))

A destination change you can review.

The proposed reference resolves to a channel defined in the workspace project. The trigger, filter, and customer lookup keep their existing definitions.

Static design examples · No checker runs in this page

04 / A direction, with clear boundaries

The idea is connected config.
The starting point is open source.

Open Ontology is experimental v0.1. This page explores how a Zapier prelude could fit into that work.

Available in this repository

The modeling foundation.

TypeScript and Forma authoring, a portable JSON-safe ontology IR, model checks, and a local in-memory Triplex runtime. The agent guide documents the current ontology prelude.

Read the current agent guide
Proposed in this study

A Zapier prelude.

Zap declarations, connected platform imports, cross-project checking, and native workflow output. These need implementation and validation against Zapier’s supported interfaces. This page has no Zapier API connection or deployment capability.

Read the package boundary

Build the vocabulary with us

Make the connections explicit.

Explore the foundation. Bring a workflow. Help shape the prelude.

Join the conversation