How to Use Logs and Runs in MyRapidi to Troubleshoot Your Integration
When your integration throws an error, the first question is always the same: where do I look? In MyRapidi, logs and runs give you that answer. They show exactly what happened, which transfer caused it, how long it took, and what the error message says. Once you know how to read them, troubleshooting becomes a lot faster.
This article walks through what runs and logs are, how they work together, and how to use them to diagnose and fix issues in your integration.
A Quick Summary
Runs
Show you every execution event with status, duration, and a link to the log entries inside.
Logs
Give you the details inside each run: record counts, error messages, and which system sent the error.
Albert
Helps you interpret cryptic error messages directly from the log entry.
Message formula
Adds field values to your logs, allowing you to identify specific records when error messages are vague.
Filters
Let you cut through large lists of logs and find exactly what you need.
Watch the Full Session
This article is based on Session 8 of Rapidi's Open Office Hours training program. The full session includes a live walkthrough of runs and logs in MyRapidi, a real error message example, and a demo of Albert in action.
What Is a Run?
A run is a single execution event. Every time a schedule fires or you manually run a transfer, MyRapidi creates a run record that groups everything that happened in that moment.
For example, if you have a schedule set to run every hour, you will see one run entry per hour. Each entry shows the date and time, the source and destination systems, the description (schedule name or transfer name), how long it took, and a status icon.
The status icons tell you at a glance:
- Green checkmark: the run completed without issues
- Red icon: something failed and needs attention
- Yellow (processing): the transfer is still running
Runs also show you two types of execution. An "S" next to a run means it was triggered by the scheduler. An "M" means it was run manually, for example after you updated a mapping or wanted to test something.
You can get to the runs page directly from Logs > Runs, or from the Schedules page by clicking the runs icon next to a specific schedule. The second option is useful when you want to see runs for one schedule only.
What Are Runs Used For?
Runs serve four main purposes:
- Track executions. See every run in chronological order with date, time, source, and destination. This gives you a full picture of what has run and when.
- Spot errors fast. The status icons flag failed runs immediately. You can also filter to show only runs with errors, so you skip past everything that ran cleanly.
- Measure duration. Each run shows how long it took. If a transfer that normally runs in 2 minutes is suddenly taking 15, that is a signal worth investigating. This is where datetime fields and filters on your transfers make a difference because they control how much data gets pulled each run.
- Jump into log entries. From any run, you can expand the record and see the full list of log entries that belong to it. This is the fastest path to understanding what actually happened.
What Are Logs?
A log entry is a detailed record of what happened inside a transfer run. Think of a run as the parent and the log entries as the detail inside it.
Each log entry shows you the transfer name, source and destination systems, how many records were read, inserted, updated, and deleted, plus any error messages. If you have a schedule with five transfers, you will see five log entries inside a single run.
Logs are used for:
- Diagnosing errors: Red entries and error flags point to exactly where something went wrong and which system sent the error.
- Auditing record counts: You can check how many records moved through and verify the numbers match what you expected.
- Filtering and searching: Filter by transfer, schedule, date range, connection, or error status to find exactly what you need without scrolling through pages of entries.
- Tracing a full run: Follow a run across all its log entries to rebuild the complete picture of what happened and in what order.
How to Find and Diagnose Errors
When something fails, here is the process to follow:
-
Go to Runs. Look for the red error icon. You can also use the error status filter to show only failed runs.
-
Expand the run. Click the arrow to expand it. You will see all the log entries for that execution grouped by transfer. The one with the error will be highlighted in red.
-
Read the error message. Each entry shows the error code and description. Some systems give you a long, detailed message that points directly to the record. Others give you something short and cryptic. Either way, the log also tells you which connection sent the error, so you know whether to look at the source or the destination system.
-
Ask Albert. If the error message is unclear, click the person icon on the right side of the log entry. That opens a chat with Albert, Rapidi's AI assistant, with the error message already loaded. Albert is connected to the Rapidi wiki and can suggest what the error means and what to check next.
If Albert does not give you a clear answer, search the Rapidi wiki directly using keywords from the error message. If you still cannot resolve it, reach out to support.
One thing worth knowing: the error message in the log comes from the destination system, not from Rapidi itself. So if you are sending data from Business Central to Salesforce and something fails, the error you see is what Salesforce sent back. That tells you where to focus your attention.
The Message Formula: Adding Context to Your Logs
Some error messages do not tell you which specific record caused the problem. When that happens, the message formula can help.
The message formula is a setting you add to a transfer. It tells MyRapidi to include the value of a specific field in the log output. For example, if you are transferring customers, you could add the customer number field to the formula. Then every time that transfer runs, the log will show the customer number alongside each record, making it much easier to pinpoint which record has a problem.
You can add multiple fields to the formula if you need more context. This is especially useful for transfers where the error messages from the connected system are vague.
Filtering Runs and Logs
Both the runs page and the logs page have the same set of filters. You can filter by:
- Date and time range
- Schedule
- Group
- Transfer
- Source or destination connection
- Status (completed or error)
- Keyword search
If you go to the Schedules page and click the runs icon for a specific schedule, the runs page will open with that schedule already filtered. You can then add more filters from there to narrow things down further.
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
My error message is very short and doesn't explain what went wrong. What should I do?
Cryptic error messages are common, and the source depends on the system. Some ERPs and CRMs return very brief codes without much context. The fastest way to handle this is to click the Albert icon on the right side of the log entry. Albert opens a chat with the error already loaded and can suggest what it means and what to check. If that doesn't help, copy the error message and search the Rapidi wiki. As a last step, reach out to support with the full log entry.
How do I know if errors are coming from the source system or the destination system?
Each log entry shows an "error on connection" label that tells you exactly which system sent the error. If you are pushing data from Business Central to Salesforce and Salesforce rejects a record, the log will say the error came from the Salesforce connection. This tells you where to look. If the error comes from the source, the record likely doesn't exist or has an issue at the point of reading. If it comes from the destination, the receiving system didn't accept the data, which usually points to a field validation rule, a missing required field, or a data format mismatch.
Errors are happening but nobody notices until something breaks downstream. How can we catch them earlier?
This is one of the most common integration problems. In MyRapidi, the runs page shows a red status icon any time a transfer fails, so checking it regularly is the first step. Setting a habit of reviewing runs at the start of each day takes less than a minute. You can also use the error status filter to show only failed runs, so you don't have to scroll through everything. For teams using Continue on Error, data errors are stored separately under Logs > Data Errors and won't surface in the main run status, so that page needs its own regular review. Email notifications for data errors are also available — reach out to Rapidi support to get those set up for your service.
The same records keep failing every run. Why isn't the error going away after I check the log?
Viewing a log entry doesn't fix the underlying problem. If the same records fail repeatedly, the issue is in the data itself or in the system configuration, not in the log. Common causes include a required field in the destination system that is empty in the source, a data format that doesn't match what the receiving system expects, or a validation rule in the destination system that the record doesn't meet. Use the log's error description and the message formula (if set up) to identify the specific record, then fix it in the source or destination system. If the error is systematic across many records, check your field mappings in the transfer setup.
My transfers are taking much longer than usual. Where do I start troubleshooting?
Start with the runs page and look at the duration column. Compare recent runs against older ones to see when the slowdown started. The most common cause of slow transfers is that the datetime filter on the transfer is pulling too much data, either because it's misconfigured or because someone changed it. Check that your transfers use datetime fields correctly so only new or updated records are pulled each run, not the full dataset. If the duration looks normal but the overall schedule is slower, check whether another transfer in the same schedule is the bottleneck by expanding the run and comparing individual transfer times.
