Skip to main content

Terminology & Core Concepts

These docs reference a number of Prismatic-specific terms like instance, custom component or alert monitor. Take a moment to familiarize yourself with our core concepts and terminology.

Core Concepts

Organizations, customers, and users

Prismatic writes software for other software companies who have their own customers, so it's important to disambiguate terms like organization and customer.

When your company signs up with Prismatic, you create an organization (sometimes referred to as an "account" or "tenant"). Your organization has multiple customers whom you can manage - those are your customers. Users can be created for both your organization and your customers, with organization users having broader, company-wide roles and permissions, and customer users having permissions limited in scope to their company. To keep things separate, we often refer to organization users as "team members" in docs and the web app.

Diagram of an organization with customers

Integrations and instances

Within your organization you can assemble an integration by tying together multiple component's actions. That integration can be tested using our integration designer. Once you are satisfied with your integration, it can be published, and instances of the integration can be configured and deployed to one or many of your customers.

Instances deployed to customers can be configured using customer-specific config variables, so one integration can be uniquely deployed to multiple customers with different setups.

AcmeERP Fuel Integration in Prismatic app

Logging, monitoring, and alerting

When an integration behaves unexpectedly (takes too long to run, or fails to run to completion), you want your team to be notified. Prismatic's alert monitors can be configured to monitor your instances, and notify your team in the event of an issue. Logs of all instance runs are retained, so you can debug production issues and rapidly resolve problems.

Not all alerts indicate bad things happened - alert monitors can be configured to run when an instance is enabled (so your project management team can mark implementations as complete), or can be configured to alert a customer via Slack or Email that an integration that runs daily ran successfully.

Prismatic Terminology

TermDefinition
IntegrationA collection of logical flows and steps that move data between your app and another app that your customers use.
CustomerThis represents a business who purchases your product. There is usually a 1-to-1 correlation between customers in your app, and customers you create in Prismatic.
InstanceA copy of an integration that has been configured for a specific customer using customer-specific credentials and configuration options.
FlowA set of steps that begin with a trigger and together accomplish a specific task (like moving a type of record from one app to another). Multiple flows can exist in one integration.
ComponentReusable code that accomplishes a specific set of tasks or connects to a third-party service. Some components are utility components (like the math component), while others like the Salesforce component are considered “connectors.” Components contain actions like “Get Record” or “Create Record”, triggers which determine when a flow should run, data sources which are dynamically-populated UI elements for the configuration wizard, and connections which dictate how a connector authenticates with a third-party app.
Custom ComponentA component that you build to connect to your own or a third-party app that you integrate with .
TriggerA trigger determines when a flow should run. It can be a scheduled trigger (e.g. "run every 5 minutes on weekdays"), a webhook trigger that runs when a payload is received, or an instance lifecycle trigger (e.g. run when an instance is deployed).
ActionComponents are comprised of mutliple actions that each accomplish a specific task (like "Create Record" or "List Accounts").
Raw RequestAPIs are vast, often comprised of hundreds of endpoints. Built-in components wrap the most commonly used endpoints as actions. If an endpoint you need to interact with is not represented as an action, a Raw Request action can be used to send HTTP requests to that endpoint.
Config VariableA configuration option, presented as an input box, dropdown menu, boolean toggle, etc., that is set by a customer user when they configure and deploy an instance of your integration. Config variables are referenced throughout your integration and can be used to drive logic in your integration.
ConnectionA connection is a special type of config variable that is made up of fields for things like usernames, passwords, API keys, OAuth 2.0 secrets, host endpoints, API versions, and more - whatever a component needs to know to connect to an outside service.
Data SourceA special type of config variable that uses a customer's estabilished connection to dynamically populate a UI element with data from a third-party app. For example, a data source "List Channels" might populate a dropdown menu with list of a customer's Slack channels.
Configuration WizardWhen a customer user enables an instance of an integration, they walk through a configuration wizard where they enter credentials for connections and select values for config variables.
OAuth 2.0Open Authorization 2.0 is an authorization mechanism commonly used in integrations. Customers click a "connect" button within your configuration wizard and consent to allowing your app to access their data in a third-party app.
WebhookAn automated message that is sent from one application to another application when certain events occur. Webhooks let applications notify one another in real-time when something has changed in one system and can be used to trigger an instance's flow so the change is reflected in the other system.
MarketplaceYou can add integrations that you build to your marketplace, which allows your customers to configure and enable instances of those integrations for themselves in a self-serve manner.
Embedded MarketplaceThe marketplace can be embedded into your application, which allows your customers to configure and enable instances without leaving your app.
Embedded DesignerThis empowers your customers to build integrations for themselves from within your app.
Alert MonitorYou can alert your team via SMS, email or webhook if integrations behave in a way that you don't expect (i.e. errors occur, an integration starts taking 5 minutes when you expect it to take 5 seconds, etc).
Prism CLI ToolThe prism command-line tool allows you to manage customers, integrations, instances and custom components from the command line.
Prismatic APIThe Prismatic API is GraphQL-based, and is the same API that the Prismatic frontend and CLI tools use. You can wrap the Prismatic API in your own scripts to programmatically manage customers, deploy instances and more.