> ## Documentation Index > Fetch the complete documentation index at: https://support.fieldko.com/llms.txt > Use this file to discover all available pages before exploring further. # Integrate FieldKo with Other Systems > Plan integrations between FieldKo and your ERP, BI, and other systems, using external IDs, an integration user, and Salesforce APIs. FieldKo stores all its data in Salesforce objects, so you integrate it the same way you integrate any Salesforce data: with Salesforce APIs or a middleware tool that uses them. Use this page to plan the common retail execution integrations, set up a safe integration user, and avoid side effects on reps and FieldKo's own automation. ## User Permissions Needed | To do this | You need | | - | - | | Create users and permission sets | Manage Users and Manage Profiles and Permission Sets permissions | | Create external ID fields | Customize Application permission | ## Common Integration Patterns Most retail execution integrations follow these patterns. Use the object labels in this table to find each object in Setup > Object Manager and in your middleware. | Direction | Data | FieldKo Objects | | - | - | - | | ERP or master data to FieldKo | Stores and buying contacts | **Account**, **Contact** | | ERP to FieldKo | Product catalog | **FieldKo Product**, **FieldKo Product Category** | | ERP to FieldKo | Prices | **FieldKo Pricebook**, **FieldKo Pricebook Entry**, and **FieldKo Contract** (links a price book to an account) | | ERP or category plans to FieldKo | Ranging (the products each store should stock) | **Product Set**, **Product Set Line Item**, **Ranging Contract** | | FieldKo to ERP | Orders reps place | **FieldKo Order**, **FieldKo Order Line Item** | | FieldKo to BI or data warehouse | Visit execution, survey results, on-shelf availability | **Visit**, **Task**, **Task Survey Answer**, **Ranging**, **Ranging Line Item**, **Attendance** | For the full list of objects and how they relate, see [FieldKo Data Model](/platform/data-model) and [Export FieldKo Data and Photos](/admin/export-data). FieldKo uses its own product, price book, and order objects, not the standard Salesforce Product, Price Book, and Order objects. A connector that writes to the standard objects doesn't change what reps see in the app. Map your integration to the FieldKo objects. ### Orders to Your ERP To send orders to your ERP, have your middleware pick up new FieldKo orders and their line items, and then record the result on the order: * Add your own fields for the handoff, such as **ERP Order Number** and **ERP Status**, instead of changing **Status**. Reps choose **Status** at checkout, and the app never offers **Sent** or **Send Failed**, which FieldKo reserves. * Orders arrive when reps sync, so line items can arrive in a later batch than their order. Process an order only when its line count is complete: the **Is Total Order Line Items synced?** field is true when the order's line count matches its lines. ### Master Data from Your ERP Load master data in dependency order: accounts, then products, then price books and entries, then contracts and ranging. See [Import and Update Data](/platform/data/import). Remember that FieldKo applies its own rules, for example: * When a FieldKo product becomes **Inactive**, FieldKo deactivates its price book entries and product set lines. * When an account's owner changes, FieldKo can move future visits and share recent orders with the new owner, depending on **Transfer Data On Change Of Account Owner**. See [Remove a Rep's Access](/admin/installation#remove-a-reps-access). * Reps get only the price books linked to their accounts through an active FieldKo contract, and that are active and valid today. See [Set Up Products, Ordering, and Ranging](/admin/products-ordering-ranging). ## Use External IDs and Upsert The FieldKo packages don't include external ID fields on accounts, products, or price books. Create your own, so your integration can upsert records by the ERP's key instead of storing Salesforce record IDs: 1. On each object you load, create a text field, such as **ERP Product Code**, and select **External ID** and **Unique**. 2. Upsert records on that field. Reference parent records by their external IDs too, for example a FieldKo Pricebook Entry's **FieldKo Product** by **ERP Product Code**. Every custom field on Account syncs to the app. Keep integration-only account fields few and short. See [Which Fields Sync](/admin/offline-data#which-fields-sync). ## Set Up an Integration User Run each integration as its own user, never as a rep or admin: 1. Create a user with the **Salesforce Integration** user license, if your contract includes it, and an API-only profile. For license options, see [User Licenses](https://help.salesforce.com/s/articleView?id=sf.users_understanding_license_types.htm\&type=5) in Salesforce Help, or ask your Salesforce account executive. 2. Create a permission set that grants only the object and field access the integration needs, such as read on FieldKo orders and edit on FieldKo products. Assign it to the integration user. 3. If your org assigns licenses for the FieldKo packages, assign the integration user a license for each package whose objects it uses. 4. Assign your automation bypass permission set. See [Avoid Triggering Rep-Facing Automation](#avoid-triggering-rep-facing-automation). The integration user doesn't need a FieldKo permission set, because it doesn't use the FieldKo Atlas app. For access design, see [Profiles, Permission Sets, and Permission Set Groups](/platform/access/permission-sets). ## Choose an API or Tool | Option | Use It For | | - | - | | Middleware or an iPaaS connector | Scheduled two-way syncs with your ERP, with mapping, retries, and monitoring | | [REST API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/) | Small, frequent changes, such as sending each new order | | [Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/) | Large loads, such as a full price file or a nightly product refresh | | [Change Data Capture](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/) | Pushing changes, such as new orders, to another system as they happen | | [Platform events](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/) | Sending your own business events from a flow, such as "order approved" | Which objects you can use with Change Data Capture, and how many events you can deliver, depends on your edition and add-ons. Check your Salesforce contract or ask your Salesforce account executive. Every API call counts toward your org's API allocation, which the FieldKo Atlas app also uses when reps sync. See [API and Platform Limits](/platform/integrations/limits). ## Avoid Triggering Rep-Facing Automation Large loads can fire your own flows thousands of times, such as manager alerts on every order. Give integration users a custom permission, and check it in your flows. See [Bypass Your Flows for Integration Users](/platform/automate/design-automation#bypass-your-flows-for-integration-users). FieldKo's own triggers and flows always run, for integration users too. Records you load must follow FieldKo's rules: for example, every visit needs an account, a sales representative, and a date inside an active call cycle for that rep. If a bulk load fails with time or CPU limit errors, reduce the batch size in your tool. ## See Also * [API and Platform Limits](/platform/integrations/limits) * [Import and Update Data](/platform/data/import) * [Export FieldKo Data and Photos](/admin/export-data) * [Design Automation for FieldKo](/platform/automate/design-automation) * [FieldKo Data Model](/platform/data-model) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.