HubSpot

Salesforce

Mailchimp

Outreach

Salesloft

Marketo

# Push contact to a list

This scenario lets you add a contact to a list for a number of supported applications. It consists of:

- a `get-lists` action which allows you to fetch all lists availble in the app
- a `push-contact-to-a-list` flow that actually adds a contact to the list you've chosen previously

# How it works

- First off, you may want to run the `get-lists` action to get the lists a contact can be added to.
- Pick a specific list Id from the action output.
- Now that you've made your mind which list you want a contact to be added, you can proceed to the `push-contact-to-a-list` flow.
  There are a few input parameters you should configure to make the flow fully operational:

  - `list_id` [string]: the ID of a list you've got earlier
  - `contact` [object]: an object that consists of the contact information you want to create in an app. Make sure its `email` property is not empty

- When the flow runs, it would try to find an matching contact by its email and add it to the list you've provided. In case contact with that email cannot be found, a new one would automatically be created with the data you've provided in the `contact` object, and immediately added to a list


Push Contacts To List

Create or add an existing contact to a list/campaign

Gmail

Microsoft Outlook

# Send Email

Implementation time: 10 minutes.

This scenario lets your application send Email from Gmail or Outlook. Email fields will be mapped from schema supported by your application to the application-specific schema

## How it works

It consists of a single `send-email` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across Gmail and Outlook in a consistent way.

When used, it transforms your Email data into a format compatible with the selected external app. Then, it makes an API call to create Emails in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `send-email` action via REST API or integration.app SDK with the data you wish to send Email with.


Send Email

Send an email via Gmail or Microsoft Outlook

# Two-way realtime sync of Drive Items
Implementation time: 30 minutes.

This scenario lets your application to sync Drive Items from your app to any external application and backwards. 
It will do initial import/export of Drive Items from your App. Then it will send events when new Drive Item is created/updated or deleted as close to realtime as possible.

Drive Item fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Drive Items
Initial import of Drive Items implemented via single `get-drive-items` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Drive Items in selected external application. 
It also use `drive-items` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Drive Items page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-drive-items` action via REST API or integration.app SDK in a loop to get all the Drive Items page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Drive Item events from external application

To keep Drive Items in sync after initial import from external application this scenario contains 3 flows:

- Receive Drive Item Deleted Event
- Receive Drive Item Updated Event
- Receive Drive Item Created Event

Each of them starts with the trigger, that launch the flow, when the Drive Item is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Drive Item data will be send to your API. 

They also store the relationg between Drive Item ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Drive Items in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Drive Items

To send Drive Items to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Drive Item in External App
- Update Drive Item in External App
- Create Drive Item in External App

Each starts with App Event triggers, that launch the flow, when `drive-item-event` event is send to Integration.app from your app backend and will create / update or delete Drive Item in External App

The relationg between Drive Item ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Drive Items in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Drive Item data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Drive Items

Bi-directional realtime sync of Drive Items with records deduplication

# Two-way realtime sync of Eeocs
Implementation time: 30 minutes.

This scenario lets your application to sync Eeocs from your app to any external application and backwards. 
It will do initial import/export of Eeocs from your App. Then it will send events when new Eeoc is created/updated or deleted as close to realtime as possible.

Eeoc fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Eeocs
Initial import of Eeocs implemented via single `get-eeocs` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Eeocs in selected external application. 
It also use `eeocs` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Eeocs page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-eeocs` action via REST API or integration.app SDK in a loop to get all the Eeocs page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Eeoc events from external application

To keep Eeocs in sync after initial import from external application this scenario contains 3 flows:

- Receive Eeoc Deleted Event
- Receive Eeoc Updated Event
- Receive Eeoc Created Event

Each of them starts with the trigger, that launch the flow, when the Eeoc is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Eeoc data will be send to your API. 

They also store the relationg between Eeoc ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Eeocs in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Eeocs

To send Eeocs to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Eeoc in External App
- Update Eeoc in External App
- Create Eeoc in External App

Each starts with App Event triggers, that launch the flow, when `eeoc-event` event is send to Integration.app from your app backend and will create / update or delete Eeoc in External App

The relationg between Eeoc ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Eeocs in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Eeoc data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Eeocs

Bi-directional realtime sync of Eeocs with records deduplication

Gusto

Workable

BambooHR

Google Workspace

# Two-way realtime sync of Employees
Implementation time: 30 minutes.

This scenario lets your application to sync Employees from your app to any external application and backwards. 
It will do initial import/export of Employees from your App. Then it will send events when new Employee is created/updated or deleted as close to realtime as possible.

Employee fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Employees
Initial import of Employees implemented via single `get-employees` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Employees in selected external application. 
It also use `employees` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Employees page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-employees` action via REST API or integration.app SDK in a loop to get all the Employees page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Employee events from external application

To keep Employees in sync after initial import from external application this scenario contains 3 flows:

- Receive Employee Deleted Event
- Receive Employee Updated Event
- Receive Employee Created Event

Each of them starts with the trigger, that launch the flow, when the Employee is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Employee data will be send to your API. 

They also store the relationg between Employee ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Employees in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Employees

To send Employees to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Employee in External App
- Update Employee in External App
- Create Employee in External App

Each starts with App Event triggers, that launch the flow, when `employee-event` event is send to Integration.app from your app backend and will create / update or delete Employee in External App

The relationg between Employee ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Employees in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Employee data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Employees

Bi-directional realtime sync of Employees with records deduplication

# Get all Drive Items
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Drive Items from any external application. Drive Item fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-drive-items` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Drive Items in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Drive Items page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-drive-items` action via REST API or integration.app SDK in a loop to get all the Drive Items page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Drive Items defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Drive Items

Imports all Drive Items from any external application to your App.

Zoho CRM

Pipedrive

Xero

Sage Accounting

Shopify

Zoho Books

Stripe

Freshdesk

Woocommerce

BigCommerce

Ontraport

Chargebee

# Get all Products
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Products from any external application. Product fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-products` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Products in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Products page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-products` action via REST API or integration.app SDK in a loop to get all the Products page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Products defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Products

Imports all Products from any external application to your App.

# Two-way realtime sync of Files
Implementation time: 30 minutes.

This scenario lets your application to sync Files from your app to any external application and backwards. 
It will do initial import/export of Files from your App. Then it will send events when new File is created/updated or deleted as close to realtime as possible.

File fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Files
Initial import of Files implemented via single `get-files` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Files in selected external application. 
It also use `files` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Files page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-files` action via REST API or integration.app SDK in a loop to get all the Files page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted File events from external application

To keep Files in sync after initial import from external application this scenario contains 3 flows:

- Receive File Deleted Event
- Receive File Updated Event
- Receive File Created Event

Each of them starts with the trigger, that launch the flow, when the File is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event File data will be send to your API. 

They also store the relationg between File ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Files in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Files

To send Files to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete File in External App
- Update File in External App
- Create File in External App

Each starts with App Event triggers, that launch the flow, when `file-event` event is send to Integration.app from your app backend and will create / update or delete File in External App

The relationg between File ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Files in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with File data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Files

Bi-directional realtime sync of Files with records deduplication

# Two-way realtime sync of Bills
Implementation time: 30 minutes.

This scenario lets your application to sync Bills from your app to any external application and backwards. 
It will do initial import/export of Bills from your App. Then it will send events when new Bill is created/updated or deleted as close to realtime as possible.

Bill fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Bills
Initial import of Bills implemented via single `get-bills` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Bills in selected external application. 
It also use `bills` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Bills page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-bills` action via REST API or integration.app SDK in a loop to get all the Bills page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Bill events from external application

To keep Bills in sync after initial import from external application this scenario contains 3 flows:

- Receive Bill Deleted Event
- Receive Bill Updated Event
- Receive Bill Created Event

Each of them starts with the trigger, that launch the flow, when the Bill is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Bill data will be send to your API. 

They also store the relationg between Bill ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Bills in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Bills

To send Bills to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Bill in External App
- Update Bill in External App
- Create Bill in External App

Each starts with App Event triggers, that launch the flow, when `bill-event` event is send to Integration.app from your app backend and will create / update or delete Bill in External App

The relationg between Bill ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Bills in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Bill data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Bills

Bi-directional realtime sync of Bills with records deduplication

# Two-way realtime sync of Suppliers
Implementation time: 30 minutes.

This scenario lets your application to sync Suppliers from your app to any external application and backwards. 
It will do initial import/export of Suppliers from your App. Then it will send events when new Supplier is created/updated or deleted as close to realtime as possible.

Supplier fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Suppliers
Initial import of Suppliers implemented via single `get-suppliers` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Suppliers in selected external application. 
It also use `suppliers` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Suppliers page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-suppliers` action via REST API or integration.app SDK in a loop to get all the Suppliers page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Supplier events from external application

To keep Suppliers in sync after initial import from external application this scenario contains 3 flows:

- Receive Supplier Deleted Event
- Receive Supplier Updated Event
- Receive Supplier Created Event

Each of them starts with the trigger, that launch the flow, when the Supplier is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Supplier data will be send to your API. 

They also store the relationg between Supplier ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Suppliers in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Suppliers

To send Suppliers to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Supplier in External App
- Update Supplier in External App
- Create Supplier in External App

Each starts with App Event triggers, that launch the flow, when `supplier-event` event is send to Integration.app from your app backend and will create / update or delete Supplier in External App

The relationg between Supplier ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Suppliers in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Supplier data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Suppliers

Bi-directional realtime sync of Suppliers with records deduplication

MS Dynamics CRM

Freshsales

Copper

Close

Google Calendar

# Two-way realtime sync of Activities
Implementation time: 30 minutes.

This scenario lets your application to sync Activities from your app to any external application and backwards. 
It will do initial import/export of Activities from your App. Then it will send events when new Activity is created/updated or deleted as close to realtime as possible.

Activity fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Activities
Initial import of Activities implemented via single `get-activities` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Activities in selected external application. 
It also use `activities` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Activities page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-activities` action via REST API or integration.app SDK in a loop to get all the Activities page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Activity events from external application

To keep Activities in sync after initial import from external application this scenario contains 3 flows:

- Receive Activity Deleted Event
- Receive Activity Updated Event
- Receive Activity Created Event

Each of them starts with the trigger, that launch the flow, when the Activity is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Activity data will be send to your API. 

They also store the relationg between Activity ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Activities in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Activities

To send Activities to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Activity in External App
- Update Activity in External App
- Create Activity in External App

Each starts with App Event triggers, that launch the flow, when `activity-event` event is send to Integration.app from your app backend and will create / update or delete Activity in External App

The relationg between Activity ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Activities in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Activity data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Activities

Bi-directional realtime sync of Activities with records deduplication

# Two-way realtime sync of Leads
Implementation time: 30 minutes.

This scenario lets your application to sync Leads from your app to any external application and backwards. 
It will do initial import/export of Leads from your App. Then it will send events when new Lead is created/updated or deleted as close to realtime as possible.

Lead fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Leads
Initial import of Leads implemented via single `get-leads` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Leads in selected external application. 
It also use `leads` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Leads page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-leads` action via REST API or integration.app SDK in a loop to get all the Leads page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Lead events from external application

To keep Leads in sync after initial import from external application this scenario contains 3 flows:

- Receive Lead Deleted Event
- Receive Lead Updated Event
- Receive Lead Created Event

Each of them starts with the trigger, that launch the flow, when the Lead is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Lead data will be send to your API. 

They also store the relationg between Lead ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Leads in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Leads

To send Leads to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Lead in External App
- Update Lead in External App
- Create Lead in External App

Each starts with App Event triggers, that launch the flow, when `lead-event` event is send to Integration.app from your app backend and will create / update or delete Lead in External App

The relationg between Lead ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Leads in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Lead data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Leads

Bi-directional realtime sync of Leads with records deduplication

ActiveCampaign

Front

# Two-way realtime sync of Emails
Implementation time: 30 minutes.

This scenario lets your application to sync Emails from your app to any external application and backwards. 
It will do initial import/export of Emails from your App. Then it will send events when new Email is created/updated or deleted as close to realtime as possible.

Email fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Emails
Initial import of Emails implemented via single `get-emails` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Emails in selected external application. 
It also use `emails` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Emails page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-emails` action via REST API or integration.app SDK in a loop to get all the Emails page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Email events from external application

To keep Emails in sync after initial import from external application this scenario contains 3 flows:

- Receive Email Deleted Event
- Receive Email Updated Event
- Receive Email Created Event

Each of them starts with the trigger, that launch the flow, when the Email is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Email data will be send to your API. 

They also store the relationg between Email ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Emails in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Emails

To send Emails to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Email in External App
- Update Email in External App
- Create Email in External App

Each starts with App Event triggers, that launch the flow, when `email-event` event is send to Integration.app from your app backend and will create / update or delete Email in External App

The relationg between Email ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Emails in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Email data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Emails

Bi-directional realtime sync of Emails with records deduplication

# Create Folder
Implementation time: 10 minutes.

This scenario lets your application create Folder in any external application. Folder fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-folder` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Folder data into a format compatible with the selected external app. Then, it makes an API call to create Folders in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-folders` action via REST API or integration.app SDK with the data you wish to create Folder with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Folder, including any custom fields.

Create Folder

Creates Folder in any external application

# Two-way realtime sync of Ledger Accounts
Implementation time: 30 minutes.

This scenario lets your application to sync Ledger Accounts from your app to any external application and backwards. 
It will do initial import/export of Ledger Accounts from your App. Then it will send events when new Ledger Account is created/updated or deleted as close to realtime as possible.

Ledger Account fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Ledger Accounts
Initial import of Ledger Accounts implemented via single `get-ledger-accounts` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Ledger Accounts in selected external application. 
It also use `ledger-accounts` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Ledger Accounts page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-ledger-accounts` action via REST API or integration.app SDK in a loop to get all the Ledger Accounts page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Ledger Account events from external application

To keep Ledger Accounts in sync after initial import from external application this scenario contains 3 flows:

- Receive Ledger Account Deleted Event
- Receive Ledger Account Updated Event
- Receive Ledger Account Created Event

Each of them starts with the trigger, that launch the flow, when the Ledger Account is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Ledger Account data will be send to your API. 

They also store the relationg between Ledger Account ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Ledger Accounts in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Ledger Accounts

To send Ledger Accounts to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Ledger Account in External App
- Update Ledger Account in External App
- Create Ledger Account in External App

Each starts with App Event triggers, that launch the flow, when `ledger-account-event` event is send to Integration.app from your app backend and will create / update or delete Ledger Account in External App

The relationg between Ledger Account ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Ledger Accounts in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Ledger Account data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Ledger Accounts

Bi-directional realtime sync of Ledger Accounts with records deduplication

# Two-way realtime sync of Folders
Implementation time: 30 minutes.

This scenario lets your application to sync Folders from your app to any external application and backwards. 
It will do initial import/export of Folders from your App. Then it will send events when new Folder is created/updated or deleted as close to realtime as possible.

Folder fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Folders
Initial import of Folders implemented via single `get-folders` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Folders in selected external application. 
It also use `folders` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Folders page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-folders` action via REST API or integration.app SDK in a loop to get all the Folders page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Folder events from external application

To keep Folders in sync after initial import from external application this scenario contains 3 flows:

- Receive Folder Deleted Event
- Receive Folder Updated Event
- Receive Folder Created Event

Each of them starts with the trigger, that launch the flow, when the Folder is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Folder data will be send to your API. 

They also store the relationg between Folder ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Folders in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Folders

To send Folders to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Folder in External App
- Update Folder in External App
- Create Folder in External App

Each starts with App Event triggers, that launch the flow, when `folder-event` event is send to Integration.app from your app backend and will create / update or delete Folder in External App

The relationg between Folder ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Folders in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Folder data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Folders

Bi-directional realtime sync of Folders with records deduplication

# Two-way realtime sync of Campaign Members
Implementation time: 30 minutes.

This scenario lets your application to sync Campaign Members from your app to any external application and backwards. 
It will do initial import/export of Campaign Members from your App. Then it will send events when new Campaign Member is created/updated or deleted as close to realtime as possible.

Campaign Member fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Campaign Members
Initial import of Campaign Members implemented via single `get-campaign-members` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Campaign Members in selected external application. 
It also use `campaign-members` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Campaign Members page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-campaign-members` action via REST API or integration.app SDK in a loop to get all the Campaign Members page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Campaign Member events from external application

To keep Campaign Members in sync after initial import from external application this scenario contains 3 flows:

- Receive Campaign Member Deleted Event
- Receive Campaign Member Updated Event
- Receive Campaign Member Created Event

Each of them starts with the trigger, that launch the flow, when the Campaign Member is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Campaign Member data will be send to your API. 

They also store the relationg between Campaign Member ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Campaign Members in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Campaign Members

To send Campaign Members to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Campaign Member in External App
- Update Campaign Member in External App
- Create Campaign Member in External App

Each starts with App Event triggers, that launch the flow, when `campaign-member-event` event is send to Integration.app from your app backend and will create / update or delete Campaign Member in External App

The relationg between Campaign Member ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Campaign Members in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Campaign Member data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Campaign Members

Bi-directional realtime sync of Campaign Members with records deduplication

Keap

SugarCRM

Capsule CRM

Agile CRM

SalesForce Pardot

SharpSpring

Teamleader

Attio

AWeber

ADP Workforce Now

Apollo.io

Affinity

Exact Online

# Get all Contacts
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Contacts from any external application. Contact fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-contacts` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Contacts in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Contacts page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-contacts` action via REST API or integration.app SDK in a loop to get all the Contacts page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Contacts defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Contacts

Imports all Contacts from any external application to your App.

Quickbooks

Freshbooks

# Create Journal Entry
Implementation time: 10 minutes.

This scenario lets your application create Journal Entry in any external application. Journal Entry fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-journal-entry` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Journal Entry data into a format compatible with the selected external app. Then, it makes an API call to create Journal Entries in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-journal-entries` action via REST API or integration.app SDK with the data you wish to create Journal Entry with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Journal Entry, including any custom fields.

Create Journal Entry

Creates Journal Entry in any external application

# Two-way realtime sync of Drives
Implementation time: 30 minutes.

This scenario lets your application to sync Drives from your app to any external application and backwards. 
It will do initial import/export of Drives from your App. Then it will send events when new Drive is created/updated or deleted as close to realtime as possible.

Drive fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Drives
Initial import of Drives implemented via single `get-drives` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Drives in selected external application. 
It also use `drives` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Drives page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-drives` action via REST API or integration.app SDK in a loop to get all the Drives page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Drive events from external application

To keep Drives in sync after initial import from external application this scenario contains 3 flows:

- Receive Drive Deleted Event
- Receive Drive Updated Event
- Receive Drive Created Event

Each of them starts with the trigger, that launch the flow, when the Drive is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Drive data will be send to your API. 

They also store the relationg between Drive ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Drives in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Drives

To send Drives to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Drive in External App
- Update Drive in External App
- Create Drive in External App

Each starts with App Event triggers, that launch the flow, when `drive-event` event is send to Integration.app from your app backend and will create / update or delete Drive in External App

The relationg between Drive ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Drives in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Drive data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Drives

Bi-directional realtime sync of Drives with records deduplication

This use case will show how to send a message to a Slack channel

# Integration Logic

## Send Message To a Slack Channel Action

We created `send-message-to-slack-channel` action of type `create-data-record` that would send a message to a specific Slack channel, when called.
There are a few action parameters you should configure to make the action fully operational:

- `channel_id`: the ID of a slack channel you want a message to be sent to [required]
- `token_type`: whether you want a message to be sent on behalf of an authorized user or a slack app. Note that the `token_type` defaults to `bot` value, should you choose to leave it empty
- `message_blocks`: a list of blocks your message should consist of. More about the structure of building block you can read [here](https://app.slack.com/block-kit-builder/)

# Adding to Your app

To call this action from your app's front-end or backend, you need to execute the code block below:

```(javascript)
await integrationApp
  .actionInstance({
    parentKey: 'send-message-to-channel',
    integrationKey: 'slack',
    autoCreate: true,
  })
  .run({
    channel_id: 'TX123',
    text_message: 'Test msg',
  })
```


Send Message To Slack Channel

This action will send a message to a slack channel

# Get all Payrolls
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Payrolls from any external application. Payroll fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-payrolls` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Payrolls in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Payrolls page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-payrolls` action via REST API or integration.app SDK in a loop to get all the Payrolls page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Payrolls defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Payrolls

Imports all Payrolls from any external application to your App.

Asana

Github

Clickup

Zendesk

Trello Connector

Todoist

Recruitee

# Two-way realtime sync of Tasks
Implementation time: 30 minutes.

This scenario lets your application to sync Tasks from your app to any external application and backwards. 
It will do initial import/export of Tasks from your App. Then it will send events when new Task is created/updated or deleted as close to realtime as possible.

Task fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Tasks
Initial import of Tasks implemented via single `get-tasks` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Tasks in selected external application. 
It also use `tasks` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Tasks page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-tasks` action via REST API or integration.app SDK in a loop to get all the Tasks page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Task events from external application

To keep Tasks in sync after initial import from external application this scenario contains 3 flows:

- Receive Task Deleted Event
- Receive Task Updated Event
- Receive Task Created Event

Each of them starts with the trigger, that launch the flow, when the Task is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Task data will be send to your API. 

They also store the relationg between Task ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Tasks in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Tasks

To send Tasks to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Task in External App
- Update Task in External App
- Create Task in External App

Each starts with App Event triggers, that launch the flow, when `task-event` event is send to Integration.app from your app backend and will create / update or delete Task in External App

The relationg between Task ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Tasks in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Task data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Tasks

Bi-directional realtime sync of Tasks with records deduplication

# Two-way realtime sync of Customers
Implementation time: 30 minutes.

This scenario lets your application to sync Customers from your app to any external application and backwards. 
It will do initial import/export of Customers from your App. Then it will send events when new Customer is created/updated or deleted as close to realtime as possible.

Customer fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Customers
Initial import of Customers implemented via single `get-customers` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Customers in selected external application. 
It also use `customers` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Customers page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-customers` action via REST API or integration.app SDK in a loop to get all the Customers page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Customer events from external application

To keep Customers in sync after initial import from external application this scenario contains 3 flows:

- Receive Customer Deleted Event
- Receive Customer Updated Event
- Receive Customer Created Event

Each of them starts with the trigger, that launch the flow, when the Customer is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Customer data will be send to your API. 

They also store the relationg between Customer ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Customers in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Customers

To send Customers to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Customer in External App
- Update Customer in External App
- Create Customer in External App

Each starts with App Event triggers, that launch the flow, when `customer-event` event is send to Integration.app from your app backend and will create / update or delete Customer in External App

The relationg between Customer ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Customers in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Customer data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Customers

Bi-directional realtime sync of Customers with records deduplication

Greenhouse Harvest

Ashby

Lever

# Two-way realtime sync of Jobs
Implementation time: 30 minutes.

This scenario lets your application to sync Jobs from your app to any external application and backwards. 
It will do initial import/export of Jobs from your App. Then it will send events when new Job is created/updated or deleted as close to realtime as possible.

Job fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Jobs
Initial import of Jobs implemented via single `get-jobs` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Jobs in selected external application. 
It also use `jobs` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Jobs page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-jobs` action via REST API or integration.app SDK in a loop to get all the Jobs page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Job events from external application

To keep Jobs in sync after initial import from external application this scenario contains 3 flows:

- Receive Job Deleted Event
- Receive Job Updated Event
- Receive Job Created Event

Each of them starts with the trigger, that launch the flow, when the Job is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Job data will be send to your API. 

They also store the relationg between Job ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Jobs in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Jobs

To send Jobs to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Job in External App
- Update Job in External App
- Create Job in External App

Each starts with App Event triggers, that launch the flow, when `job-event` event is send to Integration.app from your app backend and will create / update or delete Job in External App

The relationg between Job ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Jobs in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Job data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Jobs

Bi-directional realtime sync of Jobs with records deduplication

# Two-way realtime sync of Meetings
Implementation time: 30 minutes.

This scenario lets your application to sync Meetings from your app to any external application and backwards. 
It will do initial import/export of Meetings from your App. Then it will send events when new Meeting is created/updated or deleted as close to realtime as possible.

Meeting fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Meetings
Initial import of Meetings implemented via single `get-meetings` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Meetings in selected external application. 
It also use `meetings` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Meetings page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-meetings` action via REST API or integration.app SDK in a loop to get all the Meetings page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Meeting events from external application

To keep Meetings in sync after initial import from external application this scenario contains 3 flows:

- Receive Meeting Deleted Event
- Receive Meeting Updated Event
- Receive Meeting Created Event

Each of them starts with the trigger, that launch the flow, when the Meeting is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Meeting data will be send to your API. 

They also store the relationg between Meeting ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Meetings in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Meetings

To send Meetings to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Meeting in External App
- Update Meeting in External App
- Create Meeting in External App

Each starts with App Event triggers, that launch the flow, when `meeting-event` event is send to Integration.app from your app backend and will create / update or delete Meeting in External App

The relationg between Meeting ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Meetings in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Meeting data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Meetings

Bi-directional realtime sync of Meetings with records deduplication

# Two-way realtime sync of Journal Entries
Implementation time: 30 minutes.

This scenario lets your application to sync Journal Entries from your app to any external application and backwards. 
It will do initial import/export of Journal Entries from your App. Then it will send events when new Journal Entry is created/updated or deleted as close to realtime as possible.

Journal Entry fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Journal Entries
Initial import of Journal Entries implemented via single `get-journal-entries` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Journal Entries in selected external application. 
It also use `journal-entries` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Journal Entries page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-journal-entries` action via REST API or integration.app SDK in a loop to get all the Journal Entries page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Journal Entry events from external application

To keep Journal Entries in sync after initial import from external application this scenario contains 3 flows:

- Receive Journal Entry Deleted Event
- Receive Journal Entry Updated Event
- Receive Journal Entry Created Event

Each of them starts with the trigger, that launch the flow, when the Journal Entry is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Journal Entry data will be send to your API. 

They also store the relationg between Journal Entry ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Journal Entries in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Journal Entries

To send Journal Entries to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Journal Entry in External App
- Update Journal Entry in External App
- Create Journal Entry in External App

Each starts with App Event triggers, that launch the flow, when `journal-entry-event` event is send to Integration.app from your app backend and will create / update or delete Journal Entry in External App

The relationg between Journal Entry ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Journal Entries in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Journal Entry data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Journal Entries

Bi-directional realtime sync of Journal Entries with records deduplication

Monday

Jira

Microsoft Sharepoint

Microsoft Teams

Calendly

Basecamp

Breezy HR

Okta

Deel

# Get all Users
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Users from any external application. User fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-users` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Users in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Users page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-users` action via REST API or integration.app SDK in a loop to get all the Users page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Users defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Users

Imports all Users from any external application to your App.

# Create Invoice
Implementation time: 10 minutes.

This scenario lets your application create Invoice in any external application. Invoice fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-invoice` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Invoice data into a format compatible with the selected external app. Then, it makes an API call to create Invoices in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-invoices` action via REST API or integration.app SDK with the data you wish to create Invoice with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Invoice, including any custom fields.

Create Invoice

Creates Invoice in any external application

# Create File
Implementation time: 10 minutes.

This scenario lets your application create File in any external application. File fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-file` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your File data into a format compatible with the selected external app. Then, it makes an API call to create Files in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-files` action via REST API or integration.app SDK with the data you wish to create File with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of File, including any custom fields.

Create File

# Get all Meetings
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Meetings from any external application. Meeting fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-meetings` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Meetings in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Meetings page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-meetings` action via REST API or integration.app SDK in a loop to get all the Meetings page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Meetings defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Meetings

Imports all Meetings from any external application to your App.

# Get all Jobs
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Jobs from any external application. Job fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-jobs` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Jobs in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Jobs page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-jobs` action via REST API or integration.app SDK in a loop to get all the Jobs page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Jobs defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Jobs

Imports all Jobs from any external application to your App.

Sage HR

Personio

Rippling HR

HiBob

# Get all Employees
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Employees from any external application. Employee fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-employees` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Employees in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Employees page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-employees` action via REST API or integration.app SDK in a loop to get all the Employees page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Employees defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Employees

Imports all Employees from any external application to your App.

# Get all Documents
Implementation time: 10 minutes.

This scenario lets your application read a complete list of Documents from any external application. Document fields will be mapped from application-specific schema to the schema supported by your application.

## How it works
It consists of a single `get-documents` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Documents in selected external application. It transforms the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Documents page by page, returning a “cursor” used to fetch the next page until there is no more pages.

## Adding to your app
To use this scenario in your app, you will call the `get-documents` action via REST API or integration.app SDK in a loop to get all the Documents page by page. To get each next page, you will use the cursor returned by the previous page.

## Extension Options

You can modify this scenario by adding:

- Filter to select a subset of the Documents defined by you or by your customers.
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from external app to yours, including any custom fields.

Get all Documents

Imports all Documents from any external application to your App.

# Create Deal
Implementation time: 10 minutes.

This scenario lets your application create Deal in any external application. Deal fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-deal` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Deal data into a format compatible with the selected external app. Then, it makes an API call to create Deals in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-deals` action via REST API or integration.app SDK with the data you wish to create Deal with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Deal, including any custom fields.

Create Deal

Confluence

Notion

Google Docs

# Continuously import Documents to my App
Implementation time: 30 minutes.

This scenario lets your application to continiously sync Documents from external application to your app API. 

It will handle initial import of Documents as well as keep them in sync after Document is getting created/updated or deleted in external application.

When receiving Documents data from external application it will be transformed into the format supported by your App API, you can make your customers able to customize that data mapping based on their specific external application setup.

## How it works

### Initial import of Documents
Initial import of Documents implemented via single `get-documents` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which means that it works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Documents in selected external application. 
It also use `documents` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Documents page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use it in your app, you will call the `get-documents` action via REST API or integration.app SDK in a loop to get all the Documents page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Document events from external application

To keep Documents in sync after initial import from external application this scenario contains `get-document-events` flow.
It has 3 triggers:

- `Data Record Created trigger` to send you newly created records.
- `Data Record Updated trigger` for updated records.
- `Data Record Deleted trigger` for deleted records.

If this flow is enabled for customer, when the Document is created, updated or deleted in external application - this flow will be launched. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events))

Triggers are only guaranteed to return record ID. To get the all fields of created and updated triggers are connected to the `Find Record by Id` node that will fetch a full Document record.

All triggers and `Find Record by Id` node use shared Data Source and Field Mapping, so they will always be listening for the events of the same data in external app and give you the data in the format supported by your app

Document data you receive is passed to the `API Request to My App` node that will send full Document data to your API via the request you specify.

#### Adding to your app

To use this flow, you need to create a Customer Flow instance of this flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


Continuously Import Documents to my App

Import Documents, download Documents content and receive created/updated or deleted events

# Create Deal Product
Implementation time: 10 minutes.

This scenario lets your application create Deal Product in any external application. Deal Product fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-deal-product` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Deal Product data into a format compatible with the selected external app. Then, it makes an API call to create Deal Products in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-deal-products` action via REST API or integration.app SDK with the data you wish to create Deal Product with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Deal Product, including any custom fields.

Create Deal Product

Creates Deal Product in any external application

# Continuously import Users to my App
Implementation time: 30 minutes.

This scenario lets your application to continiously sync Users from external application to your app API. 

It will handle initial import of Users as well as keep them in sync after User is getting created/updated or deleted in external application.

When receiving Users data from external application it will be transformed into the format supported by your App API, you can make your customers able to customize that data mapping based on their specific external application setup.

## How it works

### Initial import of Users
Initial import of Users implemented via single `get-users` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which means that it works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Users in selected external application. 
It also use `users` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Users page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use it in your app, you will call the `get-users` action via REST API or integration.app SDK in a loop to get all the Users page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted User events from external application

To keep Users in sync after initial import from external application this scenario contains `get-user-events` flow.
It has 3 triggers:

- `Data Record Created trigger` to send you newly created records.
- `Data Record Updated trigger` for updated records.
- `Data Record Deleted trigger` for deleted records.

If this flow is enabled for customer, when the User is created, updated or deleted in external application - this flow will be launched. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events))

Triggers are only guaranteed to return record ID. To get the all fields of created and updated triggers are connected to the `Find Record by Id` node that will fetch a full User record.

All triggers and `Find Record by Id` node use shared Data Source and Field Mapping, so they will always be listening for the events of the same data in external app and give you the data in the format supported by your app

User data you receive is passed to the `API Request to My App` node that will send full User data to your API via the request you specify.

#### Adding to your app

To use this flow, you need to create a Customer Flow instance of this flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


Continuously Import Users to my App

Import Users and receive created/updated or deleted events

# Continuously import Ledger Accounts to my App
Implementation time: 30 minutes.

This scenario lets your application to continiously sync Ledger Accounts from external application to your app API. 

It will handle initial import of Ledger Accounts as well as keep them in sync after Ledger Account is getting created/updated or deleted in external application.

When receiving Ledger Accounts data from external application it will be transformed into the format supported by your App API, you can make your customers able to customize that data mapping based on their specific external application setup.

## How it works

### Initial import of Ledger Accounts
Initial import of Ledger Accounts implemented via single `get-ledger-accounts` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which means that it works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Ledger Accounts in selected external application. 
It also use `ledger-accounts` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Ledger Accounts page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use it in your app, you will call the `get-ledger-accounts` action via REST API or integration.app SDK in a loop to get all the Ledger Accounts page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Ledger Account events from external application

To keep Ledger Accounts in sync after initial import from external application this scenario contains `get-ledger-account-events` flow.
It has 3 triggers:

- `Data Record Created trigger` to send you newly created records.
- `Data Record Updated trigger` for updated records.
- `Data Record Deleted trigger` for deleted records.

If this flow is enabled for customer, when the Ledger Account is created, updated or deleted in external application - this flow will be launched. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events))

Triggers are only guaranteed to return record ID. To get the all fields of created and updated triggers are connected to the `Find Record by Id` node that will fetch a full Ledger Account record.

All triggers and `Find Record by Id` node use shared Data Source and Field Mapping, so they will always be listening for the events of the same data in external app and give you the data in the format supported by your app

Ledger Account data you receive is passed to the `API Request to My App` node that will send full Ledger Account data to your API via the request you specify.

#### Adding to your app

To use this flow, you need to create a Customer Flow instance of this flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


Continuously Import Ledger Accounts to my App

Import Ledger Accounts and receive created/updated or deleted events

# Create Drive
Implementation time: 10 minutes.

This scenario lets your application create Drive in any external application. Drive fields will be mapped from schema supported by your application to the application-specific schema 

## How it works
It consists of a single `create-drive` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way.

When used, it transforms the your Drive data into a format compatible with the selected external app. Then, it makes an API call to create Drives in that specific application.

## Adding to your app

To use this scenario in your app, you will call the `create-drives` action via REST API or integration.app SDK with the data you wish to create Drive with.

## Extension Options

You can modify this scenario by adding:
- [Data Source](https://console.integration.app/w/0/docs/building/data-sources) configuration that lets your customer point integration to a different type of object or list of objects in the external application.
- [Field Mapping](https://console.integration.app/w/0/docs/building/field-mappings) configuration that lets your customer configure how data is mapped from schema supported by your application to external app schema of Drive, including any custom fields.

Create Drive

Creates Drive in any external application

# Two-way realtime sync of Job Candidates
Implementation time: 30 minutes.

This scenario lets your application to sync Job Candidates from your app to any external application and backwards. 
It will do initial import/export of Job Candidates from your App. Then it will send events when new Job Candidate is created/updated or deleted as close to realtime as possible.

Job Candidate fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Job Candidates
Initial import of Job Candidates implemented via single `get-job-candidates` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Job Candidates in selected external application. 
It also use `job-candidates` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Job Candidates page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-job-candidates` action via REST API or integration.app SDK in a loop to get all the Job Candidates page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Job Candidate events from external application

To keep Job Candidates in sync after initial import from external application this scenario contains 3 flows:

- Receive Job Candidate Deleted Event
- Receive Job Candidate Updated Event
- Receive Job Candidate Created Event

Each of them starts with the trigger, that launch the flow, when the Job Candidate is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Job Candidate data will be send to your API. 

They also store the relationg between Job Candidate ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Job Candidates in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Job Candidates

To send Job Candidates to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Job Candidate in External App
- Update Job Candidate in External App
- Create Job Candidate in External App

Each starts with App Event triggers, that launch the flow, when `job-candidate-event` event is send to Integration.app from your app backend and will create / update or delete Job Candidate in External App

The relationg between Job Candidate ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Job Candidates in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Job Candidate data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Job Candidates

Bi-directional realtime sync of Job Candidates with records deduplication

# Continuously import Deals to my App
Implementation time: 30 minutes.

This scenario lets your application to continiously sync Deals from external application to your app API. 

It will handle initial import of Deals as well as keep them in sync after Deal is getting created/updated or deleted in external application.

When receiving Deals data from external application it will be transformed into the format supported by your App API, you can make your customers able to customize that data mapping based on their specific external application setup.

## How it works

### Initial import of Deals
Initial import of Deals implemented via single `get-deals` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which means that it works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Deals in selected external application. 
It also use `deals` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Deals page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use it in your app, you will call the `get-deals` action via REST API or integration.app SDK in a loop to get all the Deals page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Deal events from external application

To keep Deals in sync after initial import from external application this scenario contains `get-deal-events` flow.
It has 3 triggers:

- `Data Record Created trigger` to send you newly created records.
- `Data Record Updated trigger` for updated records.
- `Data Record Deleted trigger` for deleted records.

If this flow is enabled for customer, when the Deal is created, updated or deleted in external application - this flow will be launched. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events))

Triggers are only guaranteed to return record ID. To get the all fields of created and updated triggers are connected to the `Find Record by Id` node that will fetch a full Deal record.

All triggers and `Find Record by Id` node use shared Data Source and Field Mapping, so they will always be listening for the events of the same data in external app and give you the data in the format supported by your app

Deal data you receive is passed to the `API Request to My App` node that will send full Deal data to your API via the request you specify.

#### Adding to your app

To use this flow, you need to create a Customer Flow instance of this flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


Continuously Import Deals to my App

Import Deals and receive created/updated or deleted events

# Two-way realtime sync of Job Interviews
Implementation time: 30 minutes.

This scenario lets your application to sync Job Interviews from your app to any external application and backwards. 
It will do initial import/export of Job Interviews from your App. Then it will send events when new Job Interview is created/updated or deleted as close to realtime as possible.

Job Interview fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Job Interviews
Initial import of Job Interviews implemented via single `get-job-interviews` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Job Interviews in selected external application. 
It also use `job-interviews` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Job Interviews page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-job-interviews` action via REST API or integration.app SDK in a loop to get all the Job Interviews page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Job Interview events from external application

To keep Job Interviews in sync after initial import from external application this scenario contains 3 flows:

- Receive Job Interview Deleted Event
- Receive Job Interview Updated Event
- Receive Job Interview Created Event

Each of them starts with the trigger, that launch the flow, when the Job Interview is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Job Interview data will be send to your API. 

They also store the relationg between Job Interview ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Job Interviews in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Job Interviews

To send Job Interviews to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Job Interview in External App
- Update Job Interview in External App
- Create Job Interview in External App

Each starts with App Event triggers, that launch the flow, when `job-interview-event` event is send to Integration.app from your app backend and will create / update or delete Job Interview in External App

The relationg between Job Interview ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Job Interviews in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Job Interview data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Job Interviews

Bi-directional realtime sync of Job Interviews with records deduplication

# Two-way realtime sync of Contacts
Implementation time: 30 minutes.

This scenario lets your application to sync Contacts from your app to any external application and backwards. 
It will do initial import/export of Contacts from your App. Then it will send events when new Contact is created/updated or deleted as close to realtime as possible.

Contact fields will be mapped from the schema supported by your application to the application-specific schema.

## How it works

### Initial import of Contacts
Initial import of Contacts implemented via single `get-contacts` [action](https://console.integration.app/w/0/docs/building/actions). It is a universal action which works across many external applications in a consistent way. 

When used, it makes API calls to get a list of objects that represent Contacts in selected external application. 
It also use `contacts` Field Mapping configuration to transform the response into a consistent structure your app can work with without you knowing details of external application API.

It fetches Contacts page by page, returning a “cursor” used to fetch the next page until there is no more pages.

#### Adding to your app
To use this scenario in your app, you will call the `get-contacts` action via REST API or integration.app SDK in a loop to get all the Contacts page by page. To get each next page, you will use the cursor returned by the previous page.

### Receiving created/updated or deleted Contact events from external application

To keep Contacts in sync after initial import from external application this scenario contains 3 flows:

- Receive Contact Deleted Event
- Receive Contact Updated Event
- Receive Contact Created Event

Each of them starts with the trigger, that launch the flow, when the Contact is created, updated or deleted in external application. It will happen as close to realtime as possible ([read more about it here](https://console.integration.app/w/0/docs/building/data-sources/data-source-events)). Then it sends request with event Contact data will be send to your API. 

They also store the relationg between Contact ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Contacts in your App or External application.

#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. Customer Flow will start listening for the events for this particular customer and will automatically launch, when event occur


### Export of Contacts

To send Contacts to an external application and keep them in sync after initial export scenario has 3 flows:

- Delete Contact in External App
- Update Contact in External App
- Create Contact in External App

Each starts with App Event triggers, that launch the flow, when `contact-event` event is send to Integration.app from your app backend and will create / update or delete Contact in External App

The relationg between Contact ID in your App and ID from external application inside Integration.app Data Link Table. 
This relation is used to get related record Id, when deleting or updating Contacts in your App or External application.


#### Adding to your app

To use these flows, you need to create a Customer Flow instance of each flow for your customer via REST API or integration.app SDK. 
And send POST request with Contact data, event type and customer ID to Global Webhook URI of App Event



Two-way realtime sync of Contacts

Bi-directional realtime sync of Contacts with records deduplication

Integration Scenarios

Popular scenarios:

Push Contacts To List

Works with:

Send Email

Works with:

Two-way realtime sync of Drive Items

Two-way realtime sync of Eeocs

Two-way realtime sync of Employees

Works with:

Get all Drive Items

Get better integration infrastructure for your SaaS product today.