Tags and Reusability in Rapidi
You have three subsidiaries running the same ERP. Each one needs the same Salesforce integration - same fields, same logic, same schedule. Do you really need three separate sets of transfers?
This article covers how Tags in Rapidi let you parameterize transfers so the same configuration works across multiple companies, regions, or environments - without duplicating anything.
A Quick Summary
- Tags let you parameterize transfers so one configuration works across multiple companies or regions
- Instead of duplicating transfers, you define variables (Tags) that get resolved at runtime
- Common use cases: multi-company ERP setups, regional deployments, dev/test/prod environments
- Tags reduce maintenance - change the logic once, it applies everywhere
- Best practice: identify what varies between companies (endpoints, filters, field values) and make those Tags
Watch the Full Session
Watch the full 30-minute walkthrough below.
What Are Tags in Rapidi?
Tags are variables you define at the company or environment level that get injected into your transfers at runtime. Think of them as configuration parameters that let you write one transfer and run it in multiple contexts.
For example, if you integrate Salesforce with three Dynamics 365 Business Central companies, the transfer logic (which fields to map, what order to sync, how to handle errors) is identical. The only difference is which BC company the data flows to. Tags let you define that company as a variable.
When to Use Tags
Tags are most valuable when you have:
- Multiple companies in the same ERP that need the same integration
- Regional deployments where the logic is identical but endpoints or filters differ
- Dev/test/production environments that should mirror each other
- Seasonal or temporary variations that need to be switched without rebuilding transfers
How Tags Work in Practice
In MyRapidi, you define Tags as key-value pairs at the connection or schedule level. When a transfer runs, Rapidi resolves the Tag values and injects them into the appropriate fields - connection strings, filter conditions, default values, or any other configurable element.
This means you maintain one set of transfer definitions and one set of field mappings. The Tags handle the variation.
Setting Up Your First Tag
The setup process involves three steps:
- Identify what varies between your companies or environments (usually connection details, company codes, or filter values)
- Create Tag definitions in MyRapidi with meaningful names
- Reference Tags in your transfers using the Tag syntax wherever the variable value should appear
Multi-Company Integration Patterns
The most common pattern is a hub-and-spoke setup: one Salesforce org connected to multiple ERP companies. Each company gets its own Tag set, but they all share the same transfers, mappings, and schedules.
This pattern scales well - adding a new company means creating a new Tag set and activating it, not rebuilding the entire integration.
Common Mistakes to Avoid
- Over-tagging: Not everything needs to be a Tag. If a value is the same across all companies, hardcode it.
- Inconsistent naming: Use a clear naming convention for Tags (e.g.,
COMPANY_CODE, BC_ENDPOINT) so they are self-documenting.
- Forgetting to test: Always test a Tag change in a non-production context first, especially if it affects connection strings or filters.
Frequently Asked Questions
Can I use Tags in field mappings?
Yes. Tags can be referenced in field mappings, default values, filter conditions, and connection settings.
How many Tags can I create?
There is no practical limit. Create as many as you need to parameterize your setup.
Do Tags affect performance?
No. Tag resolution happens before the transfer runs and adds negligible overhead.
