Changelog | Ampersand

Changelog

When an enterprise agent wants to know when a specific field changes, they must listen to Salesforce change events and filter the non-relevant changes.

The problem is Salesforce has no native way to filter updates for specific fields, and every change event will be sent. Salesforce allocation is shared for all integrations across an organization, and these events can easily exhaust a customer’s entire quota for the day.

Ampersand now supports Change Data Capture (CDC) Quota Optimization which moves the filter inside the customer’s Salesforce, so changes to unwatched fields never become events that eat up quota.

Before · filter after delivery
The customer's Salesforce
Field changes
Events sent, allocation spent
Every change becomes a billed event. Filtering happens after delivery, which is too late to matter.
After · filter at the source
The customer's Salesforce
Field changes
Ampersand filter, running as an Apex trigger
Events sent
Only a watched change becomes an event. The rest never leave the org, so they are never counted.

How it works

For each object opted in, Ampersand adds a filter inside the customer’s Salesforce.

  1. A checkbox field is created on the object
  2. An Apex trigger sets that field whenever one of the watched fields changes
  3. Change Data Capture is configured to emit events only when the field is true

Changes to other fields never produce an event, so allocation is not spent.

Opt in

CDC quota optimization is opt-in, per object. The customer’s org keeps its allocation for the changes that matter, and every other integration in that org benefits from freed up shared allocation.

When the allocation empties, data stops flowing across every Salesforce integration in the org. Cutting an agent’s Salesforce consumption gives that capacity back to the whole org.

This applies to update events and reduces change event delivery, not REST API calls. Fetching each record still counts against the customer’s API limit.

Gmail subscribe actions shipped in May, so your agents could react to mail the moment it arrived. Calendar still had to wait for a scheduled read. The same notetaker that reacts instantly to an email would not notice the meeting it just booked until the next poll.

Ampersand now supports subscribe actions for Google Calendar, delivering creates, updates and deletes on the events object as they happen.

How a change reaches your destination

1
Your customer installs

Ampersand opens a watch channel on their primary calendar.

2
Google pushes a notification

The moment the calendar changes.

3
Ampersand fetches the change

We read the changed events and classify each as a create, update or delete.

4
Your destination receives it

A typed event, carrying the fields you asked for in your manifest.

Subscribe actions are now supported in both Gmail and Google Calendar, so an AI scheduling agent, a notetaker, or a meeting assistant works from the calendar in real time.

Connector ReadWriteSubscribe
Gmail
Google Calendar New
Subscribe delivers changes on the connected user’s primary calendar only. Other calendars the user can see are not subscribed.

The difference between a vibe-coded demo and trustworthy software is how reliably it runs in production, and reliability starts with error handling.

Ampersand now gives your agentic product two layers of protection: Sampling catches configuration problems during setup, and Notifications alert your system to failures at runtime.

Catch installation failures at setup with Sampling

Many builders are finding that their customers make a successful connection to Salesforce, but then realize it doesn’t work. The first time data is pulled is often the most critical moment, and it’s where an installation fails to pull data.

Our customers/builders asked: “Can we catch these issues during setup?” What if we could catch these errors before customers finish their configuration, rather than after the customer has moved on to other tasks?

Introducing Sampling. Sampling runs a test read to confirm that permissions and field mappings are correct before the customer finishes configuring their installation. Now configuration issues surface at setup, before the customer even leaves the page.

Without sampling: connect account → configure fields → finish setup → queue data sync → the first sync hits a permission error, and the customer has already moved on.

With sampling: connect account → configure fields → a test read runs → the error is caught so the customer can fix it right there, before leaving the page.

Sampling is now on by default. It runs automatically in the InstallIntegration component (@amp-labs/react v2.13.5+). You can also opt out with skipSampling when creating an installation via API.

Learn more about sampling in the docs →

Get notified of failures at run time with Notifications

Even with Sampling in place, integrations can still fail at run time. If a customer’s integration stops working, or never started in the first place, you want to know as soon as possible.

Previously you had to check the Ampersand dashboard or poll the Ampersand API to find out something was wrong. Now you can set up notifications on specific errors, so your system is alerted the moment a common integration error happens.

The best way to improve your customers’ experience is to build your system or agent to listen for these notifications, so you aren’t scrambling at run time.

Ampersand supports these notification types to enhance your agentic integration experience:

GroupEventNotifies you when
Connectionconnection.createda customer connects an account
connection.error a connection breaks (for example, expired or invalid credentials)
connection.refresheda connection is re-authenticated and healthy again
connection.deleteda connection is removed
Readread.schedule.paused a scheduled read is paused, usually due to an error
read.triggered.errora triggered read fails after retries are exhausted
Subscribesubscribe.create.error a real-time subscription fails to set up
Writewrite.async.donean asynchronous write completes
Installationinstallation.createdan installation is created
installation.updatedan installation's configuration changes
★ Recommended starter set. If you’re setting up, start with connection.error, read.schedule.paused, and subscribe.create.error. They cover the failures most likely to silently break a customer’s integration. See the full list of notification events →

Build reliable agents with Sampling and Notifications

If you’re leaning on on-call engineering to respond to integration errors, the highest-leverage improvement to your system is better error handling. By setting up both Sampling and Notifications, you get reliable integrations with your customers’ data on the first try, and agents that can debug in real time.

Wired together, an agent can even self-heal: catch a connection.error, prompt the customer to re-authenticate, and clear the error the moment a connection.refreshed event arrives.

Enterprise agents are autonomous, but also potentially non-deterministic. Examining code helps you debug traditional software, but with agents, you may need observability to track each step to know what actions the agent is taking in third party systems.

Seeing each operation as it runs, what triggered it, and whether it succeeded is how you can evaluate whether your agent performed its intended outcomes, or something went wrong.

Now the Ampersand Dashboard supports a beta version of improved Browse Operations that lets you monitor every read, write, subscribe, and search, across all your customers’ installations. Filter by status, action, or object to find the run you’re looking for, or inspect logs to see when certain transactions, like matching invoices, have been processed.

Ampersand Dashboard Browse Operations shows drill down details for every operation across all your customers' installations.

The Ampersand Dashboard supports enhanced debugging when an installation fails, and confirming your data is moving the way you expect, on the schedule you defined. Expand and drill down into an operation to read its logs and see a more detailed view.

Beta. Browse Operations is in beta. Find it in the dashboard under Integrations → Installations → Operations → Browse Operations (beta).

Most data moves through Ampersand using webhooks which are ideal for most builders: lightweight, flexible, and quick to set up. Your webhook receives real-time updates and processes the data before loading it into your own database.

As data volumes grow, you may want more robust infrastructure. Ampersand also streams large volumes of data through Amazon Kinesis for high-throughput pipelines.

However there are cases where you need a persistent data storage to hold onto data until you’re ready to process it. Ampersand now delivers your customers’ bulk data to a new destination: directly to your own Amazon S3 bucket.

Destination Processing Best for
Webhooks Real-time Reacting and processing real-time events
Kinesis Real-time streaming Streaming high volumes at scale
Amazon S3New Async, batched Storing bulk data to process later

Set it up

1In the dashboard
Destination namemyDataLake
Bucketmy-company-lake
Regionus-west-2
Access Key IDAKIA…EXAMPLE
Secret Access Key••••••••
Storage classSTANDARD
2In amp.yaml
# reference the destination by name
specVersion: 1.0.0
integrations:
  - name: syncToLake
    provider: hubspot
    read:
      objects:
        - objectName: contacts
          destination: myDataLake

The destination name in amp.yaml matches the S3 destination you created in the dashboard.

Move bulk data to storage you control, then process it on your own schedule.

A campaign dashboard pulls from several corners of HubSpot Marketing at once.

Building one means stitching together five different entities, each with its own relationships and dependencies. Ampersand now powers your enterprise agents to assemble campaign insights and dashboards from HubSpot Marketing.

To build a campaign dashboard you need:

  • The campaign: the container for a specific marketing initiative.
  • The assets: the emails and forms sent as part of the campaign.
  • The contacts: the people who engaged.
  • The associations: the links that connect the campaign to its assets, contacts, and activity.
  • The activity: the timeline of engagement that drove pipeline.
Campaign campaigns
Assets emails · forms what was sent
Contacts contacts who engaged
Activity activity the engagement timeline

Together, these five give your agents a campaign dashboard: the assets in each campaign, how many contacts engaged, and a timeline of the activity that drove pipeline. Ampersand keeps the dashboard current with scheduled reads, so new engagement shows up without you rebuilding the sync.

Build on HubSpot Marketing

With the HubSpot Marketing connectors, you can also build:

  • Campaign performance dashboards: emails, forms, who engaged, and the campaign funnel.
  • Marketing attribution: matching a campaign with contacts, activity, and pipeline revenue.
  • AI SDR engagement signals: opened marketing emails and other buy signals.
  • Lead scoring: mapping engagement events to scoring models.
  • Revenue intelligence: revenue attribution for marketing events.

Enterprise agents not only need to just read from a CRM, they need access into communication and scheduling tools to send follow-ups, book meetings, and take notes. Not only do they need read and write access, they also need the ability to react in real time.

Ampersand now supports subscribe actions for email and org-level permissions for calendars, across both our Google and Microsoft connectors.

Email subscribe actions

Subscribe actions let an integration react the moment new mail arrives, unlocking AI SDR agents and prospecting workflows that must respond in real time rather than on a polling schedule.

  • Gmail: read emails and messages, create drafts, and subscribe to get notified when new messages arrive.
  • Microsoft Outlook Mail: previously proxy-only, Outlook Mail now supports read and write actions, with real-time subscribe on the roadmap.

Calendar org-level permissions

Previously calendars only allowed account-based permissions. Ampersand now supports org-level permissions, letting applications integrate with company-wide calendars for centralized planning and for applications like AI notetakers that need org access to every meeting.

  • Google Calendar: read every calendar in the org via Google Workspace domain-wide delegation, and create and update events with write actions.
  • Microsoft Outlook Calendar: now a fully managed connector with read and write actions, with org-wide access via Microsoft admin consent in progress.
Connector ReadWriteSubscribe
Gmail New
Microsoft Outlook Mail New In progress
Google Calendar In progress
Microsoft Outlook Calendar New In progress

Company-wide calendar access, powered by platform-level permissions:

Platform Org-wide calendar access
Google (Workspace delegation) New
Microsoft (Admin Consent) In progress

Empower your agents

By supporting read, write, and subscribe across our Google and Microsoft email and calendar connectors, Ampersand enables your agents to manage, schedule, and coordinate meetings while streamlining message coordination.

These connectors now power enterprise agents including AI SDRs, AI notetakers, meeting assistants, and revenue intelligence that tracks account timelines and attribution.

Enterprise buyers are getting stricter about what third-party agents can access. They want integration permissions to be least-privilege, and are more hesitant to hand over their master keys.

Until now, the standard path was a Salesforce Connected App, which required the customer’s admin to grant “Use Any API Client” access. Many enterprise security teams are now reluctant to approve this high-privileged access.

Now Ampersand supports deploying your Salesforce integration through External Client Apps (ECAs). Once you’ve set up your ECA, it ships as a managed package that each of your customers installs into their own org.

Because the app lives inside their org, the customer’s admin installs it directly, with no org-wide “Use Any API Client” master key.

Setting it up

1
Create your ECA

Register an External Client App in Salesforce.

2
Package it

Publish it as a managed package and get an install URL.

3
Customer installs

Your customer's admin installs the package into their org.

4
Connect

They authorize, and your integration is live with scoped access.

Salesforce has phased out creating new Connected Apps, so your agents will need to move to External Client Apps. Ampersand still supports existing Connected Apps, so you can migrate on your own timeline.

When enterprise agents want to connect their customers’ systems of record like Salesforce or NetSuite, they need a way for the customer to log in and configure their objects and data mappings.

Ampersand provides an embeddable component, <InstallIntegration/>, which builders can embed into their platform to handle their customers’ authentication and data-provider configuration, including object and field mapping.

One limitation of the base <InstallIntegration/> flow is that the installation is created as soon as the first object is configured, then updated for each additional object. Some integrations may require configuration of all objects before installing. However if installed before all configurations are set, the installation may prematurely deliver partial data when you’re expecting all the configured data to come together.

Ampersand now supports a new guided wizard flow for your end customers to configure their integration before creating the installation.

The InstallIntegration wizard guiding a customer through configuring objects, fields, and mappings step by step
Wizard mode walks your customer through each step before the installation is created.

The new wizard mode improves your customers’ experience by guiding them through the configuration of each object, its fields, and mappings, with less complexity shown all at once.

How to enable

  • Upgrade to @amp-labs/react v2.13.1 or later.
  • Pass the variant="wizard" prop to <InstallIntegration/>.
Beta. Wizard mode is released in beta preview. Please see the docs for feature parity details and to stay up to date.

Enterprise finance and operations agents serve as core business functions for your customers including billing, invoicing, reconciliation. But the finance team needs to track the whole business across accounting, sales, and inventory. Your customers need your agent to stay in sync with their ERP as their internal source of truth, which may already be wired to customer-specific workflows you can’t afford to change.

The first ERP everyone hits: NetSuite. In a 2026 CFO technology survey of 1,364 finance leaders, NetSuite held 58–67% market share among companies with $50–$500M in revenue. But integrating is rarely as simple as calling a standard REST endpoint. To reach the full surface of a customer’s account, you navigate:

  • Records: transactions, accounts, custom objects, fields, and record types unique to each instance
  • SuiteScript: NetSuite’s server-side scripting language
  • REST Web Services: NetSuite’s REST-based web-services API
  • M2M auth: machine-to-machine (OAuth 2.0) authorization required to call the account
  • RESTlets: SuiteScript endpoints your customer installs to expose native, custom API access

Ampersand now handles this entire surface for you: M2M auth handshake, REST Web Services + API interfaces, and schema introspection. Finally, the hardest last mile is writing the custom APIs needed for transactions specific to a customer’s system; Ampersand creates these custom APIs for your agents with NetSuite RESTlets.

Your agent
Ampersand
One interface
Your customer's NetSuite instance
Records SuiteScript REST Web Services M2M Auth RESTlets Last mile

Automate business-specific transactions with custom endpoints

Writing into your customers’ NetSuite with the standard REST API is not the same as writing a business-specific transaction. NetSuite is built so each customer can architect their ERP around their specific business, and those transactions may be more custom and powerful than the public REST API.

Since Oracle can’t ship an endpoint for every possible business need, RESTlets allow building custom endpoints. These can be tailored to the fields you need to add, such as your platform’s transaction ID, or to write a customer’s data in the specific way their existing workflows rely on.

One endpoint, every tax engine.

One example is writing a tax workflow into a customer's NetSuite. Your customers may not have a choice in supporting only the modern workflows; they may be required to still run NetSuite Legacy Tax, which the standard REST API may have limitations.

A SuiteScript RESTlet can enable your platform to post tax across customers using both Legacy Tax and SuiteTax, introspecting their engine and selecting the workflows the system runs.

Standard REST API
1POST /invoice
2PATCH /invoice/{id}
3POST /inventoryAdjustment
3–5 sequential calls for one operation: each is a failure point you handle.
Does not support Legacy Tax
Custom RESTletNew
POST /restlet/postTransaction1 call
Runs inside · chooses correct Tax workflow
invoice
taxLegacy TaxSuiteTax
inventory
One call for the whole operation, instead of a chain you orchestrate.
Supports both SuiteTax and Legacy Tax under the same integration.
Observability into governance limits and retries.

Ampersand packages this RESTlet as a NetSuite bundle that your customer installs into their account. From there, Ampersand manages and maintains the bundle for you. Your agents can introspect the account’s schemas and call its custom endpoints to post the transactions the business runs on across sales, inventory, tax, and your custom fields.

Now your agents can act inside your customers’ ERP, reliably writing data the way each customer’s business expects.

NetSuite RESTlet support is currently in private preview. See docs for details.

Your agent doesn’t always need the entire record. One record may be enough. Instead of pulling every record into the context window, an agent can query on demand for just the records it needs, avoiding context bloat and cutting token usage.

Ampersand now supports a new primitive: Search actions. Search actions let you find records when you know part of a record and need to fetch the rest, or need to find a record in order to update it.

ActionWhat it does
readRequest a list of records
writeCreate or update a record
subscribeReceive updates when records change
proxyAuthenticated passthrough for raw API access
searchNewQuery records by criteria, on demand

Leaner enterprise agents

Reading a whole object into an agent’s context is expensive and can lead to bloat. Search lets the agent ask for only what it needs.

With read
Agent context
Every record loads, leading to context bloat and additional token usage.

Find, then update

Search also powers a find-then-update flow: look a record up by a value you know, get its ID back, then write the change.

Search Actions Availability

Search is available on Salesforce, HubSpot, NetSuite, and ServiceNow (May 2026)

A new take on native product integrations