For the admin or CS engineer holding a report that something did not sync, and needing to know which screen holds the answer.“It did not sync” is four different failures wearing one sentence. Introw reports each of them in a different place, on purpose: a broken connection belongs on the integration, a field nobody can write belongs on the screen where you were about to map it, and a record your CRM refused belongs on the submission that tried to create it. This guide is the map, so you open the right screen first instead of working through all four.
What you’ll achieve
You can name the layer a failure lives in, read Introw’s own words for it, and act on the cause rather than guessing: a reconnect, a permission in your CRM, a remapped property, or a corrected submission.Before you start
Know which CRM you are on
Confirm your permission
The four layers
Work top down. Each layer only makes sense once the one above it is healthy.Steps
Layer 1: the connection
Read the status pill
Layer 2: one mapping
Find the mapping carrying a warning pill
Trust the pill: transient failures never raise one
Check the marketing funds mapping too
Layer 3: what the connection is allowed to do
This is the layer that most often reads as an Introw bug, because nothing failed. Introw runs as a CRM identity, so a mapping can be configured perfectly and still deliver less than it says: a partner count that is short, a submission that saved without half its values. Introw checks the connection’s actual access and marks the shortfall on the screen where you would otherwise wire up something that cannot work.Read the access summary on Object linking
- “Introw has full access to these objects” closes the layer. Move to layer 4.
- “Introw acts as the CRM user behind this connection and cannot do everything here” means at least one object is limited, and the limits are marked per object below.
- “Introw could not check what this CRM connection is allowed to do” is not a clean bill of health. It means the check itself did not run, so anything below may silently do less than it says. Pipedrive lands here permanently: it has no per-connection permission model to inspect.
Read the per-object verdict
Re-check after changing permissions
Read the write verdicts on a form
- Each CRM object automation in the list carries a warning pill when the connection cannot write that object, so you know which one to open without checking each.
- Inside the automation, a Permission limitations notice lists everything that will not work, in the same wording as the table above.
- In the property picker, every property the connection cannot write is struck through with the reason beside it.
Layer 4: one record
Open the submission your CRM refused
Read a permission refusal for what it is
Fix and retry from the submission
Make sure someone hears about it
Read a workflow's own CRM step
Errors your CRM shows, not Introw
Read the Introw card in HubSpot
- Something went wrong, with “trouble with the connection, please try again later”, is a transient failure reaching Introw. It clears on its own.
- Connection lost, with “Introw is not connected to HubSpot anymore”, means authorization broke. The card carries its own Reconnect button, so a HubSpot admin can fix it without opening Introw.
Read the action history in a HubSpot workflow
What Introw does not tell you
Knowing the blind spots is half of diagnosing quickly. Four are worth planning around.A field the connection cannot write is left out, and the record still saves
A field the connection cannot write is left out, and the record still saves
No one is emailed when the connection itself breaks
No one is emailed when the connection itself breaks
Introw cannot count what your CRM hides
Introw cannot count what your CRM hides
Pipedrive has no access check
Pipedrive has no access check