Vavan Core

Action types

Named, governed operations that create and modify objects under validation, permissions, and audit — the only sanctioned way to write to Vavan Core.

An action type is a named, governed operation that creates or modifies objects in Vavan Core. Rather than letting any caller edit a record's properties or links directly, every change flows through a defined action — Advance Pipeline Stage, Create Order, Convert Lead to Customer — that knows its own rules, who may run it, and what should happen as a result.

Actions are the write side of the model. Reading Vavan Core is open traversal; writing to it is deliberately constrained, because a write can change pipeline math, trigger fulfillment, or extend credit. Naming each operation turns those changes into a vocabulary the whole system — apps, automations, and the in-app assistant — shares.

Why actions exist

Consistency — an action applies the same validation and defaults no matter who or what invokes it, so a record can never reach an invalid state through one app that another app would have rejected.
Permissions & row-level security — each action declares who is allowed to run it, evaluated together with organization-scoped row-level security so a caller can only act on objects they are entitled to.
Auditability — because every change is a named action with known inputs, it can be recorded: what changed, by whom, when, and with what parameters.
Side effects — an action can do more than mutate a field. It can raise a signal, create a task, or notify, so the right follow-on work happens automatically rather than relying on someone to remember.

Representative action types

Action	Effect	Typical side effect
Create Contact	Creates a Contact and links it to an Account.	Adds the contact to the account's people; may seed an onboarding task.
Advance Pipeline Stage	Moves an opportunity to the next stage in the controlled set.	Resets days-in-stage; may create a stage-appropriate follow-up task.
Convert Lead to Customer	Promotes a lead to a customer account.	Stamps the customer-since date; raises a welcome / kickoff signal.
Create Order	Creates an Order with line items linked to an Account and Products.	Validates credit; makes the order eligible for dispatch.
Dispatch Order to Route	Adds an order as a stop on a route.	Notifies the assigned driver; updates route sequence and ETAs.
Enroll in Outreach Sequence	Places a contact or account into an outreach sequence.	Schedules the first touch; creates follow-up tasks.
Issue Credit	Sets or adjusts an account's credit terms or limit.	Records an audit entry; may notify finance / approver.
Merge Duplicate Accounts	Combines two accounts into one, re-pointing links.	Preserves history; raises a signal if conflicts need review.
Log Activity / Call	Records an interaction against an account or contact.	Updates last-activity recency; can clear an at-risk signal.
Set Follow-up Task	Creates a task linked to an account, due at a chosen time.	Surfaces in the assignee's queue; reminders on due date.

Validation & rules

Every action declares the rules that must hold before it commits. These include required property values, enum constraints (a stage must be one of the allowed values), referential checks (an order's account and products must exist), and business rules (for example, Dispatch Order to Route may require the order to be in a fulfillable state). If validation fails, the action is rejected and nothing changes — there is no partial write.

Permissions

An action declares who can run it. Authorization is evaluated against the caller's role and against organization-scoped row-level security, so permission to run an action and access to the specific objects it touches are checked together. A user who may log a call might not be allowed to issue credit; a user in one organization can never run an action against another organization's objects. See Security for the isolation and access model.

Side effects & automation

Actions are how the closed loop stays in motion. A single action commonly fans out into follow-on work:

An action commits a change to an object (for example, Advance Pipeline Stage).
The change raises a signal — a typed observation about a record.
The signal drives a recommended next step and a task linked to the account.
Completing that task is itself another action, which may raise the next signal.

Because each step is an action with known inputs and effects, automation is predictable and auditable rather than a tangle of one-off triggers.

AI agents use the same actions

The in-app assistant does not have a private back door to the database. When an AI agent advances a stage, drafts an order, or sets a follow-up, it invokes the same action types a person would, subject to the same validation, the same permissions and row-level security, and the same audit trail. AI-initiated writes are governed identically to human writes — there is no separate, less-constrained path. This is what makes it safe to let agents act on the model.

Conceptual example

The following is a conceptual example of an action invocation, not a literal API payload:

# conceptual example — invoking an action
action: advance_pipeline_stage
target:
  object_type: Opportunity
  id: opp_4821
params:
  to_stage: Quote        # must be a valid enum value
  reason: "Pricing approved by buyer"
# evaluated under: caller permissions + organization row-level security
# on success -> records audit entry, resets days_in_stage,
#               creates follow-up task for the stage owner

Note. Actions are the only sanctioned write path into Vavan Core. This is what keeps every change — human or AI, from any app — consistent, permissioned, and recorded.

Back to the Vavan Core overview, or review object types, properties, and link types.