Skip to main content
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

1

Know which CRM you are on

Salesforce, HubSpot, and Pipedrive fail differently because their permission models differ, and the guide says so per layer.
2

Confirm your permission

Reading these surfaces needs access to Integrations, Forms, and Submissions in Introw. Fixing most of them needs admin access in your CRM.

The four layers

Work top down. Each layer only makes sense once the one above it is healthy.

Steps

Layer 1: the connection

1

Read the status pill

Go to Integrations and read the tile’s pill: Connected, Update available, Needs attention, Rate limited, Interrupted, or Not connected.A pill is a whole-connection verdict, so it is the fastest way to rule the layer out. Interrupted means authorization broke and nothing is flowing. Rate limited means your CRM throttled the sync and it will clear itself. Update available means new scopes are waiting on a CRM admin, and only the data behind those scopes has stopped.Troubleshoot a CRM connection walks each pill to its fix. Come back here when the pill reads Connected or Needs attention and something is still missing.
A broken connection does not email your team. Introw’s own on-call is alerted so support can reach out, but nothing lands in your inbox, so the Integrations page is the surface to check.

Layer 2: one mapping

1

Find the mapping carrying a warning pill

Open the CRM via Configure, then Object linking. A Needs attention connection is usually one mapping, not the whole sync: Introw isolates the failing object link, keeps syncing everything else, and marks just that row with a red warning pill.Select the row to read what broke. Introw names the likely CRM-side cause per CRM and per mapping method:Every one of these notices also says that Introw retries the mapping automatically on the next sync, which is the part people miss: you fix the CRM side and the flag clears itself. There is no button to press.
2

Trust the pill: transient failures never raise one

A warning pill means a configuration or permission problem, never a bad moment on the network. Rate limits, row locks, query timeouts, gateway blips, and dropped connections are all classified as transient and leave mapping health untouched, so they never produce a flag you would have to interpret and dismiss.The consequence is worth stating plainly: if a mapping is flagged, something in your CRM really did change.
3

Check the marketing funds mapping too

Marketing funds carry their own Object linking card, on your CRM’s mapping tab at Marketing Funds, with the same warning pill and the same meaning. A fund request or claim that stopped reaching your CRM is flagged there, not on the integration.

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.
1

Read the access summary on Object linking

Still on Object linking, the panel opens with one line about the connection itself.
  • “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.
Collapsed, the step carries a shorter version: Introw cannot see or change everything on the named objects, open this step for details.
2

Read the per-object verdict

Each linked object carries a two or three word pill, with the full reasoning on hover. This is the vocabulary to learn, because it is the same wording on every screen that shows it.
Partly visible is one-sided by design. Your CRM cannot report records the connection is not allowed to see, so Introw can tell you the view is partial but never how much is missing.
3

Re-check after changing permissions

The access answer is cached, so an admin who has just granted the missing permission would otherwise keep reading the old warning and conclude the fix did not work. Use Re-check after changing permissions on the panel to re-probe immediately.
4

Read the write verdicts on a form

Reads are only half of it. Open a form at Forms and go to its Automation tab, where the same check runs against writes.
  • 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.
The reasons are worth separating, because only one of them is yours to fix:Before this existed, a field the connecting user simply lacked permission on looked identical to a formula field. Reading the reason is what turns “why can I not pick this” into a permission set change.

Layer 4: one record

1

Open the submission your CRM refused

Go to Submissions. A submission whose CRM write failed carries the Error status, and Error is work rather than an outcome: the submission reached Introw and your CRM refused the record.Open it. Above the object that failed, a red panel reads Could not create followed by the object’s name, and under it a plain-language reason. The panel is internal: the partner who submitted never sees it. Introw rewrites the raw CRM refusal into a sentence a partner manager can act on, so you are reading what happened rather than a status code. The raw message is kept with the submission for support.A submission can fail on more than one object, and each failure is reported against the object it belongs to. Partner creation is reported the same way when a form was set to create the partner and could not.
2

Read a permission refusal for what it is

When your CRM refused the write on permissions rather than on data, Introw says so directly instead of paraphrasing. These are the sentences to recognise:Introw does not retry these. The same call fails the same way every time, and retrying only delays the truth reaching you. Fix the permission in your CRM, then resubmit.
3

Fix and retry from the submission

Where the cause is the submitted data, a required property left empty or a value your CRM validates, the submission stays editable and the panel tells you so: Edit the submitted fields to retry. Correct the values on the submission and the automation runs again.Where the cause is a permission or a mapping, fix that first, then use Return to ask the partner for a corrected submission. An accepted submission cannot be un-accepted, because accepting is what created the record.
4

Make sure someone hears about it

Introw emails a Submission error notification when a submission’s CRM write fails. It reaches the same internal recipients you configured under Inform partner team on that form’s Automation tab, and it is internal only: no partner ever receives it.That dependency is the operational catch. A form with no Inform partner team recipients configured sends nobody an error email, and its failed submissions wait in the inbox until someone looks. Configure recipients on every form that writes to your CRM.
5

Read a workflow's own CRM step

A CRM write from a workflow rather than a form is reported on the run. Open the workflow, read the run, and the failed node carries the reason on the node itself. See Test a workflow and read its runs.

Errors your CRM shows, not Introw

1

Read the Introw card in HubSpot

The Introw cards on HubSpot records report connection problems where the rep is standing, which is often where a problem is noticed first.
  • 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.
2

Read the action history in a HubSpot workflow

An Introw action inside a HubSpot workflow reports its failure to HubSpot, so the reason appears in that workflow’s own action history alongside every other step. Check there when a HubSpot workflow was supposed to create a partner, enroll a journey, or issue a certificate and nothing happened. See Use Introw workflow actions in HubSpot.

What Introw does not tell you

Knowing the blind spots is half of diagnosing quickly. Four are worth planning around.
On Salesforce, a field the connecting user has no write permission for is left out of the write, and the record saves without it. Nothing is marked on the record afterwards, which is why the value simply looks absent.Catch it before it happens rather than after: the Fields read-only verdict on the object and the struck-through properties in the form’s property picker both name these fields while you are still configuring. If every mapped property is unwritable, the write does fail loudly, reporting that none of the properties could be written to that object.
There is no notification for an integration going into Interrupted or for a mapping needing attention. Introw’s own team is alerted so support can reach out, but the surface your team watches is the Integrations page, plus the Introw card inside HubSpot.
Salesforce will not report records the connecting user may not see, so Partly visible is as precise as the answer gets. If a partner count looks short and the object is marked partly visible, widen sharing or grant View All on that object and re-check.
Pipedrive exposes no per-connection permission model, so the access layer reports that it could not check rather than inventing a verdict. On Pipedrive, work from layers 1, 2, and 4.

How the two CRMs differ

The same screens, a genuinely different cause behind them. Full detail per CRM: Salesforce permissions, scopes, and the integration user and HubSpot permissions and scopes.

Verify it worked

The integration reads Connected with no warning pill on any mapping, the access summary on Object linking reads that Introw has full access to those objects, the form’s Automation tab carries no Permission limitations notice, and a fresh submission on that form reaches Accepted with its record in your CRM carrying every mapped value.

Troubleshoot a CRM connection

Layer 1 end to end: every status pill and its fix.

Salesforce permissions, scopes, and the integration user

The access Introw needs, and the integration user that bounds it.

HubSpot permissions and scopes

Every scope, and what breaks when one is missing.

Connect a form to your CRM

Configure the writes whose failures land on the submission.

Test a workflow and read its runs

Read a failed CRM step inside a workflow run.

Implementation reference

Full CRM configuration options.