Connecting Code Buddy to Procore

Last Updated: September 2, 2026

Code Buddy turns site photographs into signals — potential compliance and safety issues, each tied to the requirement behind it. This integration sends the ones you choose into Procore as observations, so the work reaches the people who fix it without anyone retyping it.

What it does

An inspector captures photographs on site. Code Buddy reads them against the requirements that apply in that jurisdiction and raises a signal for each potential issue, with the requirement behind it and the photographs that show it. From the report, you choose which signals to send, who each one is assigned to, and which Procore project they belong to.

Each signal becomes a Procore observation carrying:

• what was seen, why it matters, and how to put it right
• the requirement it cites — a code section, a CFR part, an ISO standard, a project specification or your own policy, depending on what governs the work
• its corrective action plan as an attached PDF, where one has been produced — see below
• the photographs that evidence it
• a priority derived from the signal’s severity
• the assignee and location you chose

When a later inspection sees the same issue again, Code Buddy recognises it and adds a note to the existing observation rather than creating a duplicate.

A signal is not a verdict

This is the part worth reading twice. A signal is something Code Buddy noticed in a photograph — a potential issue, not a confirmed defect. Your inspector reviews each one and accepts it, marks it fine, or disputes it. You can send signals before anyone has reviewed them, and sometimes that is exactly right: getting a live hazard in front of the responsible party beats waiting.

So every observation Code Buddy files says which it is. It carries a line naming itself as a Code Buddy signal identified by automated inspection, stating whether an inspector has reviewed and accepted it or not yet, and asking the reader to verify against the governing requirement before acting. Anything Code Buddy writes afterwards — a repeat note, a resolution note, a withdrawal — says it was posted automatically.

We are explicit about this because a Procore observation is a permanent record on someone else’s project, often assigned to a subcontractor by name. The people who receive one should be able to tell, from the observation itself, how much weight it carries and who stood behind it.

Corrective action plans

A signal says what is wrong. A corrective action plan says what to do about it: the fix broken into numbered steps, each carrying the requirement it answers to. Code Buddy produces one on demand for a signal your inspector has accepted, and your team can edit it — add steps, remove them, reorder them.

When a signal that has a plan is sent to Procore, the plan is attached to the observation as a PDF. The steps arrive numbered and in order with their citations, so whoever is assigned the observation can work through it in Procore without opening Code Buddy. The observation body keeps a one-line pointer to it rather than the whole plan, because a sixteen-step plan pasted into a plain-text field is unreadable on a phone.

The PDF carries its own disclaimer, deliberately. Once the plan is a separate document it is the thing a subcontractor opens — possibly the only thing — so it repeats what the observation says about itself: that it came from a signal rather than a finding of fact, whether anyone has reviewed and accepted it yet, that it may be incomplete, inaccurate or misleading, and that the governing requirement is what to check it against.

What sends is the plan as your team left it. If someone edited the steps, the edited version is what the assignee reads — which is the point, since the person who knows the site usually knows the fix better than we do.

A plan is never required. A signal with no plan sends perfectly well and carries what was seen, why it matters and how to put it right. A plan still being written, or one that failed to generate, is left behind rather than sent half-finished — the observation goes without it. And because a plan exists only for a signal somebody accepted, an observation that arrives carrying one has been through review.

If the PDF cannot be produced for any reason, the plan is written into the observation body in full instead. A tidier observation is never worth losing the instructions somebody has to work from.

Before you start

You will need:

• a Code Buddy account with administrator access to your organisation
• a Procore account that can be used to authorise the connection, with Standard permissions on the Observations tool for every project you want signals sent to
• read access to the Procore Directory, so signals can be assigned to people

Use a dedicated account, not a personal one

The integration acts as whoever authorises it. If that person leaves your company and their Procore account is disabled, the connection stops working and has to be set up again from scratch.

Create a dedicated Procore user for the connection — something like codebuddy@yourcompany.com — add it to the projects you care about with Observations permissions, and authorise with that. It is five minutes now against an outage later, at the least convenient moment.

Connecting

1. In Code Buddy, go to Control Center → Integrations.
2. Find Procore and choose Connect.
3. Sign in to Procore with the dedicated account and approve the requested access. You will be returned to Code Buddy.
4. Map your Code Buddy workspaces to Procore projects. This is what tells Code Buddy where a site’s signals belong.

Sending signals

1. Open a signal report, on the web or in the mobile app.
2. Choose Send and tick the signals you want to send.
3. Set an assignee, severity or location for any signal that needs one.
4. Confirm. The observations appear in Procore, each with its photographs attached.

Procore emails each assignee when an observation is sent to them, which is the point — but it does mean a send is not silent. Check the project is the right one before you confirm.

Sent to the wrong project anyway? Choose Undo. Code Buddy notes on each observation that it was sent in error and releases the signals, so the same ones can be sent to the right project. It does not delete anything from Procore — removing the observations is your call, not ours.

What Code Buddy accesses

The integration reads:

• your company and project list, so you can choose where signals go
• observation types, so each signal is filed under the right one
• the project directory, so signals can be assigned to a person

And it writes:

• observations, with their photographs, priority, assignee and location
• updates and notes on observations it created — when a signal is seen again, verified as resolved, or withdrawn

It does not touch financials, schedules, drawings, submittals, RFIs, or any other Procore tool. The permissions requested are exactly the ones listed above and nothing more.

If something stops working

Signals will not send. Check the connection in Control Center → Integrations. If it shows as expired, reconnect — most often the authorising Procore account’s access has changed.

An observation has no priority, or the wrong type. Confirm the project has observation types configured in Procore. Code Buddy files each signal under the type matching its severity, and cannot create an observation without one.

Signals will not assign. The person needs to be in the project directory in Procore, and the authorising account needs read access to it.

Disconnecting

In Control Center → Integrations, choose Procore and then Disconnect. Code Buddy revokes its access token and deletes its stored credentials immediately. Observations already created stay in Procore — they are your records, in your system.

Getting help

Email ops@codebuddy.chat and tell us which project and roughly when, and we can look at exactly what was sent and what Procore answered.

Procore is a trademark of Procore Technologies, Inc. Code Buddy is not affiliated with or endorsed by Procore Technologies, Inc.