Migrating your customer integrations to Prismatic from a third-party platform or a custom in-house solution requires a good understanding of everything from terminology to architecture to the developer experience.
Prismatic is purpose-built for B2B software companies, handling the infrastructure for everything that breaks at scale – all while giving you flexible ways to build.
Knowing what to expect ahead of time sets you up for a successful transition.
Integration terms
Everyone has different terms for the pieces of an integration. For example, the integration itself might be called a template, solution, adapter, connector, or workflow. Here are several integration-related terms we use, along with their definitions.
- Code-native integration – An integration coded in the IDE of your choice with full TypeScript support and AI coding agents through our MCP dev server (instead of an integration built via the low-code designer).
- Component – A reusable code module that can be connected to an external system/service via an API or provides utility logic such as math functions, branching, or looping.
- Config variable – A setting that can be entered/changed when configuring an instance of an integration.
- Custom component – A component built specifically to connect to your product’s API or to a niche or custom third-party application.
- Customer – A company/business/organization that is using your product and its integrations.
- Data source – A config variable that uses an established app connection to populate the config UI with data dynamically.
- Embedded workflow builder – A platform feature that enables customers to create their own workflows (simplified integrations) within your product without engineering dependency.
- Integration – A collection of flows and steps (actions) that enables data transfer from one system to another. It may be deployed to one or more customers as an instance.
- Integration designer - A low-code UI that allows your users to build integrations.
Core integration structure and functions
Here’s an overview of how Prismatic integrations are set up and how they handle certain standard functions.
- Structure – Each integration is composed of one or more distinct flows (which consist of a connection, a trigger, and one or more additional steps/actions). Multiple flows in a single integration allow it to handle related tasks with a single configuration and set of connections. So, an integration could sync customers with one flow, but send alerts with a second flow.
- Data storage – You can persist small amounts of data for an integration between executions.
- Data collections – You can process arrays or lists using the provided Loop component (for serial processing). In addition, you can set up parallel processing by passing individual or multiple records to a sibling flow. The platform also supports FIFO processing to ensure that data is processed according to a strict sequence when required.
Custom code and components
If your current solution depends on custom code, Prismatic has you covered.
- Inline custom code – The code component lets you use the low-code designer to insert small snippets of code directly into a flow right where you need it. This works for things like specific data transformations. And, this code component is a unique action/step in the flow, making it simple to place correctly.
- Custom components – The platform supports custom components written in TypeScript via our SDK. These give you flexibility to embed complex logic, handle unique auth, and build data sources directly into a reusable component.
- Built-in components – The platform also provides a variety of reusable utility components in the catalog. Each of these utilities is designed to assist with integration logic and other functions to accomplish a set of specific tasks.
- Code-native development – For the ultimate in custom code management, we have code-native integrations. You can use your favorite IDE to write integrations entirely in code, but also take advantage of everything the platform provides (from auth and triggers to existing components).
Configuration and deployment
Prismatic includes built-in flexibility for integration configuration and deployment. For example, you may have an integration that is best set up and entirely configured by your onboarding team. You may also have an integration that requires customers to perform data mapping for their environment as part of the configuration. The platform enables both of these scenarios and more.
- Config wizard – Key to this flexibility is the config wizard, which can be customized per integration. The wizard consists of one or more pages and is designed to handle key configuration details, such as connections and data sources, as well as anything else that might be important to ensure an integration is set up correctly for a given customer.
- Data sources – Use them to populate the config wizard dynamically. For example, you could display the customer’s existing Slack channels as a pick list. In scenarios like this, a data source provides better contextual guidance for customers than having them manually enter a value.
- User-level configuration – Prismatic also differentiates between the customer (the B2B company for whom the integration runs) and the customer’s user. To support everything from multiple locations to multiple departments to individual users, Prismatic offers user-level configuration. This allows a single integration instance to handle multiple configurations.
- Embedded marketplace – Prismatic offers an in-app marketplace that lets you provide a native UX for customers to discover, configure, and activate integrations.
Monitoring, troubleshooting, and our API
The platform also makes things easier for your support and engineering teams.
- Monitoring and alerting – Prismatic uses alerts that can be triggered by specific conditions, such as when an execution fails or doesn’t run after N minutes. These alerts can be sent via email, SMS, or webhooks, enabling integration with existing systems such as Slack or PagerDuty. Or, you can invoke another Prismatic flow.
- Log management – While logs are available via the support and customer dashboards, Prismatic also lets you stream logs to external logging platforms such as Datadog and New Relic. This enables your team to view all the pertinent logs (from integrations, your product, related services, etc.) in a single location.
- API – Prismatic’s API uses GraphQL, offering advantages over REST APIs for fetching data and working with a single endpoint. This is the same API that the Prismatic platform uses. As a result, anything you can do via the UI, you can do via the Prismatic API or the Prism CLI.
Why teams migrate to Prismatic
The reasons teams migrate to Prismatic are as varied as the people themselves, but here are some of the common scenarios:
- Product teams migrate when integrations become a customer-acquisition bottleneck or when the integration experience is substantially disconnected from the core product.
- Engineering teams migrate when integration maintenance drains resources from core dev work or when scaling customer-specific integrations becomes unmanageable.
- Executives migrate when integration delays negatively impact revenue or when overhead costs prevent the team from saying yes to key deals.
There’s much more
The functionality we’ve touched on is not a comprehensive list by any means. It should, however, give you an idea of what you might need to change from your current in-house or third-party integration build processes when you move to Prismatic.
For more details on how you can use Prismatic to build, deploy, and manage your integrations, check out our docs.
