The Ampersand changelog

If SOQL can express it, a Salesforce read can now return it. Raw filters pass any custom conditions straight to Salesforce, which makes a read a building block for business workflows customized to each builder and each of their customers.

Raw filters

Read actions now accept a raw filter: a condition in the provider’s own query language, passed to the provider exactly as written. For Salesforce, a SOQL condition is supported; it would appear after WHERE:

Status = 'Qualified' AND (Country = 'US' OR Country = 'CA')

Salesforce applies the filter before returning the data, so only matching records are read. Filters are stored in an installation’s config and can be set during customer setup.

What raw filters unlock

Raw filters enable a whole class of customized workflows. By combining conditions in SOQL, builders can target specific datasets within a customer’s Salesforce records, optimizing read quota and supporting new use cases.

A single condition can unlock workflows such as:

• Regional pipelines: Country = 'US' OR Country = 'CA' sends one region’s leads to a pipeline of their own.
• Reconcile deletes: IsDeleted = true returns deleted records, so the builder’s database can delete them too.
• Targeted segments: Email LIKE '%@acme.com' pulls one domain’s contacts into a warehouse for analysis.
• Leaner reads: Status = 'Qualified' spends API quota and sync time only on the records a workflow uses.

These examples are only the beginning. What comes next is up to each product’s needs.

Example: reconcile deleted records

Scheduled Salesforce reads never returned deleted records. A deleted deal sits in the Recycle Bin, where reads couldn’t see it, so the builder had no way to act on the deletion. Reads with a raw filter use Salesforce’s queryAll endpoint, which also returns records still in the Recycle Bin.

The filter can now decide what comes back:

See the Salesforce provider guide for details, including deleted records.

Waiting for the first webhook to verify a customer’s subscription creates the question: has setup failed, or has no new customer data changed yet?

Ampersand now helps verify that an subscribe setup is working with observability into lifecycle events. The Ampersand dashboard now show subscribe lifecycle events and supports configuring notifications for successful or failed subscription changes.

Subscription lifecycle events

Creating, updating, or deleting an installation’s subscription now produces an operation for each subscribed object labeled: Subscription Created, Subscription Updated, Subscription Deleted.

Each subscribe operation includes logs with additional details.

Subscription notifications

Six notifications now add observability into the subscribe action lifecycle: subscribe.create, subscribe.update, and subscribe.delete, each with a .success and an .error event.

The timing of subscribe.create.success depends on the provider. For providers Ampersand subscribes to programmatically, it fires when setup succeeds. For providers whose webhooks are configured manually in their own UI, it fires when the first event is delivered.

Enterprise B2B SaaS and agentic products not only want to read and write data into their customer’s system of record, but they want to know when specific changes happened. In our most advanced deep connectors, Ampersand supports listening to these changes through our subscribe actions.

Adding real-time subscribe support to a provider previously meant work in our open-source connectors library and additional Ampersand platform work before we could fully deploy. Now subscribe actions can be added directly to our public repo without the need for platform work.

Supporting a subscribe action for a new provider in Ampersand includes:

Platform work unblocks open-source builders

Take every provider that gained real-time this summer and count how much work was required by a platform engineer.

Subscribe connector work no longer requires separate engineers to build in the Ampersand platform, which increases our open-source contributor velocity.

The path is seven documented pull requests in the connectors library, and the provider stays switched off until the last one merges.

Available now

The connectors library is public and MIT licensed, so the work behind every real-time provider is readable, including the guides describing how each one was added.

Enterprise agents often need access to not just a single user’s data but an entire organization’s data for a specific resource. Previously every user was required to login and click through consent OAuth popups. When a single user denies access, permissions and gaps in data becomes a headache. Onboarding cost scales with number of end customers.

Alternatives might include running a legacy workaround like Exchange Web Services (EWS) impersonation, which gives a service account all access permissions to act as any user in an organization. With limited security control, enterprise agents still on EWS may have no guardrails inside the mailboxes they reach and can risk exposing sensitive data.

Ampersand now supports Microsoft (Admin consent), where one tenant administrator grants consent once for the whole organization. Your integration then calls the Microsoft Graph API as an application, with no individual user signing in. With Admin consent, scopes are granular and require approval for specific permissions.

What the connector supports

• Read actions: including full historic backfill and incremental read.
• Write actions: create and update records through Graph.
• Proxy actions: call any Graph endpoint yourself, using the base URL https://graph.microsoft.com.

Because consent is granted at the tenant level, the object surface is Graph itself: users, groups, calendars, events, messages and many more.

Pick the right Microsoft connector

Both connectors stay available, and they answer different questions about whose data you are reading.

• Microsoft (Admin consent): org-wide, app-level access to the whole tenant.
• Microsoft: access scoped to an individual signed-in user.

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.

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.

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

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.

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.

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:

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.

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.

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.

Set it up

# 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.

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.

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

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

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 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/>.

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.

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.

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.

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.

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.

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)