> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Every CRM error Introw logs, and where to read it
> The four places Introw reports a CRM failure: the connection, one broken mapping, what the connection is not allowed to do, and a record your CRM refused.
> 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
Salesforce, HubSpot, and Pipedrive fail differently because their permission models differ, and the guide says so per layer.
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.
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
c["The connection
Integrations"] --> m["One mapping
Object linking"]
m --> p["What the connection may do
Object linking and form Automation"]
p --> r["One record
Submissions, workflow runs"]
```
## Steps
### Layer 1: the connection
Go to [Integrations](https://app.introw.io/settings/integrations?category=crm) 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](./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
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:
| Where it broke | What Introw says |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| HubSpot, a property mapping | The selected property no longer exists in HubSpot. Verify the object type and property configuration. |
| HubSpot, an association label | The association label no longer exists in HubSpot. Verify the label is still configured. |
| Salesforce, any mapping | Permissions are incorrect, or the object or property no longer exists. Verify your permissions and mapping configuration. |
| Salesforce, a relation table | Permissions are incorrect, or the relation table, object, or property no longer exists. |
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.
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.
Marketing funds carry their own **Object linking** card, on your CRM's mapping tab at [Marketing Funds](https://app.introw.io/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.
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**.
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.
| Verdict | What it means | Usual fix |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **Not in CRM** | Introw cannot find the object at all. It was renamed or removed. | Repoint the mapping, or restore the object. |
| **No access** | The connection can neither read nor write the object. | Grant that user access, or reconnect as a user who has it. |
| **No read access** | Nothing syncs in, however the mapping is configured. | Grant read on the object. |
| **Cannot read back** | Introw can create records but never see them again. They exist in your CRM and stay invisible in Introw and to partners, attribution never lands, and each resubmission creates another copy. | Grant read on the object. Treat this as urgent. |
| **Cannot create** | Enriching records that already exist works; anything creating a new one fails. | Grant create on the object. |
| **Read-only** | The connection can never write the object. | Grant create and edit, or drop the automation. |
| **Cannot update** | New records work; enriching existing ones does not. | Grant edit on the object. |
| **Partly visible** | The object is not shared org-wide, or field-level security hides fields. Counts, attribution, and duplicate detection cover the visible subset, not your whole CRM. | Widen sharing, or accept the subset knowingly. |
| **Fields read-only** | Named fields can be read but not written. | Grant field-level edit on those fields. |
| **Record types limited** | Record types exist that are not assigned to this user, so Introw cannot set them. | Assign the record type to the user. |
| **Visibility unknown** | Introw could not confirm whether sharing rules hide records from this user. If they do, Introw cannot see them either. | Check your sharing settings for that object. |
**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.
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.
Reads are only half of it. Open a form at [Forms](https://app.introw.io/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:
| Reason shown | What it is |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **No write permission for this connection** | A permission gap. Grant field-level edit and it becomes writable. |
| **Calculated in your CRM** | A formula or rollup. Nobody writes it, including you. |
| **Managed by your CRM** | A system field your CRM owns. |
| **Can only be set when the record is created** | Writable on create, never on update. Introw also warns that on an existing record the value is left out. |
| **Already mapped on another line** | Not a permission problem. The property is in use elsewhere in this automation. |
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
Go to [Submissions](https://app.introw.io/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.
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:
| What you read on the submission | What your CRM refused |
| --------------------------------------------------------- | ---------------------------------------------------------- |
| Not allowed to write this record or one of its fields | Record or field-level write access. |
| Cannot access a record this one links to | A linked record the connection may not see. |
| One of the fields Introw tried to write cannot be written | A field that is not writable for this connection. |
| No access to this object type | The object itself. |
| One of the values Introw tried to write is not available | A picklist value or record type the user does not have. |
| The record no longer exists, or is not visible | A deleted record, or one outside the connection's sharing. |
| Not allowed to perform this action | The operation itself. |
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.
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.
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.
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](/features/automation/workflows/guides/test-a-workflow-and-read-its-runs).
### Errors your CRM shows, not Introw
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.
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](./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.
| | Salesforce | HubSpot |
| ------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------- |
| What limits Introw | The connecting user's object CRUD, field-level security, sharing rules, and record types | The app's OAuth scopes, granted portal-wide |
| Record visibility | Can be partial, and Introw says so | Always complete within a granted scope |
| A read-only property | Can be read-only for this connection only | Read-only for everyone, including your own team |
| The fix for most verdicts | A permission set on the integration user | Re-authorizing the app for the missing scope |
| Where the fix lands | Immediately, once you re-check | On **Install update**, done by a HubSpot admin |
Full detail per CRM: [Salesforce permissions, scopes, and the integration user](./salesforce-permissions-and-scopes) and [HubSpot permissions and scopes](./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.
## Related
Layer 1 end to end: every status pill and its fix.
The access Introw needs, and the integration user that bounds it.
Every scope, and what breaks when one is missing.
Configure the writes whose failures land on the submission.
Read a failed CRM step inside a workflow run.
Full CRM configuration options.