What Link Storages Are and How to Use Them in MyRapidi
When you sync records between two systems, there has to be something that remembers which record in the source matches which record in the destination. In Rapidi, that something is called a Link Storage. It stores the primary key pairs between your systems so that transfers know whether to create a new record or update an existing one.
This article walks through what Link Storages are, how to set them up, how they handle transfers, and how to use features such as composite keys, the LS Lookup formula, and import/export.
A Quick Summary
Link Storage: A built-in lookup table that stores the primary key pairs between your source and destination systems.
Runtime updates: When a transfer runs, the Link Storage is automatically populated with the key values for every record processed.
Key fields vs. Link Storage: You can disable key fields and rely entirely on the Link Storage, or keep key fields enabled alongside it.
Composite keys: Link Storages support multiple key fields, stored as values separated by a dash.
LS Lookup formula: Let's you retrieve Link Storage values in other transfers — faster than querying the source or destination system directly.
Watch the Full Session
This article is based on Session 9 of Rapidi's Open Office Hours training program. The full session includes a live walkthrough of Link Storages in MyRapidi, a step-by-step setup demo, and examples of how Link Storages behave when transfers run.
What Is a Link Storage?
A Link Storage is a built-in Rapidi functionality that stores and retrieves system key pairs — the primary keys that identify records in each system. Think of it as a dynamic lookup table that saves the one-to-one relationship between records across your integration.
For example, in your ERP you might have a customer number like C00010. In Salesforce, that same customer has an Account ID like 001Dn00000XYZ. The Link Storage keeps that mapping so Rapidi always knows they are the same customer.
Without a Link Storage, Rapidi cannot tell whether a record already exists in the destination. Every sync would create duplicates instead of updates.
You can have as many Link Storages as you need — one, twenty, or fifty — depending on how many object types and relationships your integration covers.
How to Create a Link Storage
Setting up a Link Storage is straightforward. Before you begin, make sure your connections are configured and tested, and that you have a transfer design in mind.
-
Go to Link Storages and click New. Give it a code — something meaningful like "Accounts-DE" — and add descriptions for both sides. For example, "BC Customer Number" on the left and "Salesforce Account ID" on the right.
-
Select the source connection. Choose the connection, then the table (e.g., Customer Card), and then the key field (e.g., Number). This tells Rapidi which field to store from the source system.
-
Select the destination connection. Same process: pick the connection, table (e.g., Account), and key field (e.g., Account ID).
-
The Link Storage is ready. It will be empty until a transfer uses it. Once you assign it to a transfer and run it, entries are created automatically.
It is always connection, table, and field — on both sides. That is the structure of every Link Storage.
Using Link Storage on a Transfer
Once created, you assign a Link Storage to a transfer in the General section. When you edit the transfer, you will see a dropdown listing all available Link Storages. Select the one that matches this transfer's object type.
There are two ways to configure the relationship between Link Storages and key fields:
Option 1: Link Storage only (key fields disabled)
This is the most common and recommended setup. Disable the key fields section and let the transfer rely entirely on the Link Storage. When the transfer runs, it checks the Link Storage to see if the record exists. If it does, it updates. If not, it creates a new record and adds the entry to the Link Storage.
Option 2: Key fields enabled alongside Link Storage
You can keep key fields enabled and still have a Link Storage assigned. In this case, the transfer relies on the key fields (primary keys or external IDs) to determine creates vs. updates, but the Link Storage is still populated with every run. This is useful when you want the Link Storage data available for lookups in other transfers but prefer to use key field matching for the actual sync logic.
Important note on key fields: If you use external IDs as key fields, make sure they are both unique and marked as external IDs in the destination system. Otherwise, you risk creating duplicates.
What Happens When the Transfer Runs
Every time a transfer with a Link Storage runs, you get Link Storage statistics in the log. These show you exactly what happened:
- Get: How many records were looked up in the Link Storage
- Checked: How many entries were verified
- Updated: How many existing entries were refreshed
- Added: How many new entries were created (new records synced for the first time)
- Deleted: How many entries were removed
For example, if you send a new customer that did not exist before, you will see "1 added" in the Link Storage statistics. If you run the same transfer again and nothing has changed, you will see "1 updated" because the customer was found in the Link Storage and updated in the destination.
Using Composite Keys
Link Storages are not limited to a single key field. You can define multiple key fields on either side, and the values will be stored as a combination separated by a dash.
For example, if a table uses both a Document Type and a Document Number as its composite primary key, you can add both fields to the Link Storage. The stored value will look like: Invoice-10042 — where "Invoice" is the document type and "10042" is the document number.
You can add a third or fourth key field if needed. When the transfer runs, it populates all entries with all the fields you have defined, always separated by dashes.
The LS Lookup Formula
One of the most powerful features of Link Storages is the LS Lookup formula. This formula lets you retrieve values from a Link Storage inside a different transfer's field mappings.
For example, if you are syncing invoices and need to look up the Salesforce Account ID for a customer, you can use the LS Lookup formula to pull it from your customer Link Storage — instead of querying Salesforce directly. This is faster because it queries your own Link Storage data rather than making an API call to the source or destination system.
The LS Lookup formula is documented on the Rapidi wiki with full syntax and examples.
Managing Link Storage Entries
At the list level, you have several options for managing your Link Storage data:
- Add a new value manually: If you need to create a link between two records without running a transfer, you can add entries directly.
- Delete all entries: Clears the entire Link Storage. Use with caution — if you need these links later, they will be difficult to recover.
- Export: Downloads the full list as a JSON file to your computer. Use this before making bulk changes as a backup.
- Import: Upload a JSON file into a Link Storage. This is useful for migrating links between services or restoring from a backup. All entries in the file are created automatically.
- Search and filter: If you have hundreds of entries, use the search field on either column to find a specific record by its source or destination ID.
At the entry level, you can edit or delete individual records. Editing lets you change the key values if a record ID has changed in one of the systems.
Import and Export: Common Scenarios
The import/export functionality is particularly useful in these situations:
- Copying links between services: If you have links in one Rapidi service and need them in another, export from the source service and import into the destination service.
- Data migration: When moving to a new system, you may need to re-establish links with new record IDs. Export the current state, update the IDs in the file, and import the updated version.
- Backup before changes: Always export your Link Storage data before making bulk modifications. This gives you a rollback point.
The import file format is JSON. When you import into a Link Storage, entries are created automatically — whether you have 100 or 300 records.
Watch all sessions and register for upcoming ones: rapidionline.com/resources/open-office-hours
See the full Season 1 schedule: rapidionline.com/product-updates/open-office-hours-season-1
Frequently Asked Questions
What happens if I run a transfer without a Link Storage assigned?
If no Link Storage is assigned and key fields are also disabled, the transfer has no way to determine whether a record already exists in the destination. This means every run will create new records instead of updating existing ones, leading to duplicates. Always make sure you have either a Link Storage or key fields configured on your transfer before running it.
Can I use the same Link Storage on multiple transfers?
Yes, and this is common when multiple transfers work with the same object relationship. For example, if you have one transfer that creates customers and another that updates customer addresses, both can share the same customer Link Storage. The key requirement is that both transfers reference the same source and destination key fields that the Link Storage was set up with.
I deleted all entries in my Link Storage by accident. What should I do?
If you have a previously exported JSON file, you can import it to restore the entries. If not, you will need to rebuild the links. One approach is to re-run the transfer, but be aware that this may create duplicates in the destination if records already exist there. The safest approach is to export your Link Storage data regularly as a backup, especially before making any changes.
How do composite keys work in the Link Storage?
When you define multiple key fields on one side of a Link Storage, the values are stored as a single string separated by dashes. For example, if you use Document Type and Document Number, an entry might look like "Invoice-10042". The order matches the order in which you added the fields. You can add up to three or four key fields if your table requires a composite primary key. The transfer populates all fields automatically when it runs.
What is the difference between relying on key fields vs. relying on Link Storage?
When you rely on key fields, the transfer uses the source and destination key field values to match records — typically a primary key or external ID. The transfer queries the destination system directly to check if the record exists. When you rely on the Link Storage instead (with key fields disabled), the transfer checks its own stored mapping first. This avoids an extra query to the destination system. Both approaches work, but Link Storage-only is generally recommended because it is faster and keeps a clear audit trail of which records are linked. You can also combine both: keep key fields enabled for matching logic while still populating the Link Storage for use in other transfers via the LS Lookup formula.
