Troubleshooting: Procore Syncing
Diagnose inbound, update, and outbound sync problems between Procore and LiveArch.
Overview
Procore sync problems involve data moving in one of two directions: from Procore into LiveArch, or from LiveArch back to Procore.
This page works from high-level symptoms to likely causes to the named checks that confirm or disprove them.
If the checks don't resolve the issue, open a support ticket and note what you already tried. And before closing, deleting, or substantially changing a connected record in Procore, coordinate with the BBB project team first — see Closing or deleting connected records on Linked RFIs or Linked Submittals — so the LiveArch side doesn't end up orphaned.
Start with the symptom
The table below maps each of the three symptoms to its most likely cause and to the checks that confirm it.
| Issue | Possible causes | Troubleshooting Checks |
|---|---|---|
| An RFI or Submittal from Procore is not appearing in LiveArch | LiveArch is on the distribution list but is not the current assignee (RFI) or current reviewer (Submittal); or a required Procore field is incomplete. | Record requirements, Connection & access, ID lookup, Refresh |
| The record is in LiveArch but updated data or attachments from Procore are missing | Changes to an existing record are held in the read-only mirror for a person to reconcile — by design, they do not overwrite LiveArch silently. The changed field may also be one the integration does not sync. | ID lookup, Refresh, Webhook health |
| A finalized LiveArch response is not syncing back to Procore | The record has not actually reached its finalization step, or its response value has no matching Procore response option. | Response & return, Connection & access |
Video: Why isn't my Submittal showing up? (~90 sec)
Walking the inbound checks against a real record: assignment, sent date, the Procore ID lookup, and a Refresh.
The checks
Each check is self-contained. Run only the ones the symptom table or the error index reference, in the order given. ID lookup, Refresh, Date-range fetch, and Webhook health are performed in Project Settings → Procore Integration → Troubleshooting, which requires settings-management permission.
Record requirements
This is the single most common cause of a record never arriving. Work the checklist on the page for that record type:
- Procore-Connected Submittals — LiveArch Integration must be the current reviewer and the sent date must be set on its workflow row.
- Procore-Connected RFIs — LiveArch Integration must be the current assignee, and the record must not be a revision of an earlier RFI.
Being on Procore's distribution list or CC is not enough to route a record to LiveArch. Assignment is what triggers the sync.
Connection & access
- Open the integration tabGo to Project Settings, then the Procore Integration tab.
- Confirm the connection is verifiedConfirm the connection step reports the correct Procore company and project. If the troubleshooting tools are greyed out, this step has not been completed.
- Confirm the integration is enabledA project can be connected but switched off, which stops syncing in both directions.
- Confirm the app still has project accessIn Procore's App Management, confirm this project is still on the LiveArch app's permitted-project list — access can be removed after installation.
ID lookup
This tells you whether the problem is the sync or the record itself. Enter the Procore ID in Procore ID Lookup, choose RFI or Submittal, and read the result top to bottom: what Procore says (status and last updated), the identifier and title, whether LiveArch has a mirror of it, and whether a LiveArch record exists.
- LiveArch mirror: No — nothing has synced. The cause is upstream: go back to Record requirements and Connection & access, then Refresh.
- A LiveArch record with a status and an Open link — the record synced correctly and is in that status. If someone cannot see it, the issue is visibility or permissions, not syncing.
- Not created — LiveArch has the mirror but made no record from it, and the tool prints why (for example, LiveArch's Procore user was never sent it, or it is still a draft in Procore). Fix the cause in Procore, then run Refresh. If the LiveArch record was deleted, see the error index below.
Refresh
- Look the record up firstRun ID lookup, so you can compare the before and after state.
- RefreshSelect Refresh. LiveArch re-reads that record from Procore and then re-runs the lookup automatically after about a minute — the countdown is shown. Wait for it rather than clicking again.
- Read the refreshed resultIf a LiveArch record now shows, it has arrived. If it still reads Not created, the reason line says what is missing — almost always one of the Record requirements conditions.
Date-range fetch
Use this when several records are missing rather than one. Set a start and end date under Force-fetch RFIs or Force-fetch Submittals and start the fetch. The sync is queued and runs in the background, so the confirmation means “accepted”, not “finished” — re-check with an ID lookup afterwards.
Warning
Keep the range tight. A range longer than two weeks asks you to confirm first, because a large fetch consumes significant resources and can take a long time.
Webhook health
Webhooks are how Procore tells LiveArch a record changed, so a degraded or duplicated registration shows up as changes never arriving while brand-new records still work. The integration tab reports webhook health and offers a reinstall when it is not healthy. Reinstalling affects the whole project's syncing, so coordinate with the BBB project team first.
Response & return
- Confirm finalizationConfirm the LiveArch record has genuinely reached its finalization step and every required reviewer action is complete.
- Confirm the response contentConfirm the formal response, status, and required attachments are present.
- Confirm the response value maps to ProcoreConfirm the response value has a matching Procore option. Procore's response options are project-specific, so if the project's set has changed, open Submittal Response Mapping in the Procore Integration tab, select Fetch Submittal Response Options, and re-check the mapping.
- Return itUse Return to Procore or Submit and Sync. Wait for it to complete, then refresh the Procore record.
- Check the Procore recordConfirm the Procore record was not closed, deleted, or moved beyond the integration's expected workflow.
Warning
Do not return a response a second time unless the project team has confirmed the first attempt failed. LiveArch writes back once, and a duplicate return can advance the Procore workflow twice.
Error message index
Most sync problems produce no message at all — that is what the symptom table is for. When LiveArch does show a message, find it below: each entry gives what the message indicates and the checks that address it, grouped by the kind of problem it signals.
Warning
A failed push is not recorded anywhere: the message appears once as a notification and is gone when it clears or the page is left. Capture the exact wording, ideally as a screenshot, before doing anything else. Without it a support request has little to work from, since there is no stored history of failed attempts.
Connection & configuration
Tooltip on the troubleshooting tools. The project's connection has not been verified, so the tools are locked. Run Connection & access.
The connection could not be saved — re-check the Procore company and project IDs. A message naming a project instead usually means that Procore project is already linked to another LiveArch project; confirm which LiveArch project owns the link before changing anything.
Procore integration is not configured for this project. Finish setup in Project Settings → Procore Integration to sync.
No usable connection is saved for the project. Older Submittal paths show the first sentence on its own, without the guidance that follows it. Run Connection & access; if the connection looks complete, — the integration user may need to be re-resolved.
The Procore integration is switched off for this project. Turn it back on in Project Settings → Procore Integration to sync.
A working connection is saved, but the integration has been toggled off, which stops syncing in both directions — deliberately distinct from the not-configured message above. Turn it back on in the Procore Integration tab; if it was switched off on purpose, confirm with the project team before re-enabling.
Record not found, not visible, or not routed
The Procore ID Lookup found no mirror of that Procore item in LiveArch — nothing has synced from it. Work Record requirements and Connection & access, then Refresh.
A LiveArch record existed for this Procore item and was deleted. . Do not Refresh expecting it to return; deletion is deliberate and may need a coordinated fix.
The LiveArch Submittal record being acted on could not be found. Often the record was deleted, or the page is stale and refers to a record that no longer exists. (The RFI equivalent reads “We are unable to find current rfi.”) Refresh the module list and reopen the record; if it is genuinely gone, rather than recreating it.
No Procore approver row on that Submittal matches the LiveArch Integration user. Usually LiveArch is not (or is no longer) the current reviewer, or the workflow row was changed in Procore after the record synced. Run Record requirements, then Refresh once the workflow row is correct.
A Procore action was attempted on an RFI that has no Procore counterpart — it was created in LiveArch rather than synced in. No action needed if the RFI is genuinely standalone. If it should be linked, it has to arrive from Procore rather than be linked after the fact.
Response mapping & push blockers
The Procore response mapping for this project has not been fully configured. Please map all LiveArch responses to Procore options in Project Settings before pushing to Procore.
A LiveArch response has no mapped Procore option, so the push has no value to send. Procore response options are project-specific and must be mapped per project. Run Response & return.
Client error PATCH … resulted in a 400 'Bad Request' response. Param is missing or the value is empty: submittal_response_id
Procore's own rejection, passed through verbatim. The push reached Procore with no response id attached — the same root cause as the mapping message above. Run Response & return; if the mapping is complete and this persists, with the full message.
No message accompanies this one; the mismatch is visible on the record itself. Procore's response options are project-specific, and the project's set may have changed since it was mapped. Re-fetch and re-map the options: Response & return.
Only a finalized RFI can be pushed to Procore. / A formal reply must be authored before pushing to Procore.
The RFI has not reached the state that produces something to send. Finalize the record and author the formal reply first — Response & return.
This formal reply cannot be pushed to Procore because attachment files are missing from storage: {files}. Resolve the missing file(s) and try again.
One or more attachments on the reply are absent from storage, so the push is stopped before anything reaches Procore rather than sending an incomplete reply. The message names the specific files. Re-upload the named files to the reply, then push again; if they were never uploaded successfully, with the file names.
Already pushed & locked records
These are guardrails, not faults — LiveArch writes back exactly once, and these messages are it declining to write twice.
LiveArch writes a finalized reply back exactly once, and this one has already gone. Verify the response on the Procore record. Do not attempt a second push; a duplicate return can advance the Procore workflow twice.
The revision was finalized and pushed, so it is locked. It appears when a reconcile or finalize action is attempted on an already-pushed revision. No action needed for the pushed revision — a genuinely new question needs a new RFI rather than a change to this one.
This formal reply was recorded in Procore, not authored in LiveArch, so it cannot be pushed back to Procore.
The reply originated on the Procore side (or came from migrated legacy data), so pushing it back would echo Procore to itself. A sibling message names migrated legacy data as the source. No action needed — the response already lives in Procore.
Transient & generic failures
The background sync job was not accepted. Retry once; if it fails again, rather than clicking repeatedly.
The request itself did not complete. Retry. If it keeps failing, confirm the connection is healthy (Connection & access, Webhook health).
Procore refused the request and LiveArch passes its response through verbatim, which is why the text is raw JSON. A 403 means the project's Procore service account lacks rights on that tool — typically it is not an RFI assignee, or its permission template does not grant RFI access. This is a Procore-side permission, not a LiveArch defect. Other statuses appear in the same shape. Ask the GC's Procore administrator to grant the LiveArch Integration user access to that tool on that project, then retry; with the full message if the access looks correct.
A generic catch-all from the Submittal sync path. It carries no specific cause, so it does not narrow anything down on its own. Work Record requirements and Connection & access, then send the details in What to send support — this one usually needs the server-side log to diagnose.
What to send support
If the issue continues, with:
- LiveArch project name, and the Procore company and project name.
- Record type and number, plus the Procore ID you looked up.
- Which of the three directions it is: never arrived, arrived but stale, or not returning.
- Which checks you already ran, and what the Procore ID Lookup reported.
- Date and approximate time of the attempted sync.
- Current Procore assignee or reviewer.
- Screenshot of any message or unexpected state.
- Whether the record was recently reassigned, closed, deleted, or revised.
Warning
Do not send passwords, access tokens, or other credentials in a support request.
Support
Questions or issues? We're happy to help — , or use the contact form if you're signed out.