Chris M. / 28 July 2026 / Reviewed 11 August 2026

Can I Tailor-Make Procore, Asite or 4Projects to My Business?

A quality manager wants an inspection and test plan tool that follows the firm's own three-part form, the one a client body has required for years. The platform sales call goes well. Custom fields, yes. Workflows, yes. Then the detail arrives: ten custom fields on this tool, thirty on that one, and the specific field the firm actually needs does not exist as a type the platform supports at all.

That gap between "yes, it's configurable" and what actually lands on the screen is the real subject of this question, and it is worth answering with the platforms' own technical documentation rather than their sales copy, because the two say noticeably different things.

What "configurable" actually means, tool by tool

Procore's own support documentation is unusually candid about where configuration stops. Custom fields exist across 24 tools, but the limit is hard: most tools allow 10, commitments allow 30, document management allows 20.¹ Fifteen field types are available, not all of them in every tool, and in the Documents tool "custom fields are always optional" and cannot be marked required.² Custom workflows, the part of the platform that actually changes step names, approval sequencing and assignee roles, are narrower still: Procore's own list names Payments, Budget, Commitments, Correspondence, Document Management, Invoicing and Prime Contracts.³ Change orders and owner invoices sit as items inside the Commitments and Prime Contracts workflows rather than as tools with a workflow of their own. Everything else in Procore runs on the vendor's fixed process.

Oracle Aconex draws its line even tighter, and does so structurally rather than through a limit you might negotiate around. Its documents API exposes named, numbered slots for customer fields: ProjectField1 through ProjectField3, SelectList1 through SelectList10.⁴ You are not adding fields to a schema. You are filling in slots the schema already defines, and when they run out, they run out.

Autodesk Construction Cloud, since renamed Forma, sits closer to Procore: its documented Issues API describes retrieving custom attribute definitions, without describing any way to create or change one through the API itself, so real customisation of what an issue can capture happens through the admin interface rather than through integration.⁵ Asite is the outlier worth knowing about, because it is the only platform in this set that markets a genuine build-your-own layer, called AppBuilder, described as letting a firm "develop, test, and deploy custom applications to fit your business."⁶ Its actual technical limits sit behind a gated developer guide that is not publicly documented, so treat the marketing claim as a starting point for a sales conversation rather than a specification you can plan against before you see it.

The API is not the escape hatch it appears to be

If the built-in configuration will not stretch far enough, the next instinct is to build a connector against the platform's API instead. That route carries its own limits, and they are contractual as much as technical.

Procore deliberately does not publish a fixed rate limit, and its documentation actively warns developers against assuming a round number: "Don't assume a single fixed window (for example, only 3600/hour). Always use the current response headers as the source of truth."⁷ Oracle Aconex is far more restrictive and far more explicit about it: a hard limit of five requests per second and ten concurrent requests per organisation, enforced by the API itself.⁸ For a firm trying to bulk-extract or bulk-load records for its own ITP register, that ceiling shapes how the integration has to be built from day one.

The contractual terms matter as much as the rate limits. Oracle's API terms for Aconex bar a customer from disclosing "any benchmarking or availability testing of the Aconex APIs," which means you cannot even publish an honest account of how the integration performed.⁹ They also cap Oracle's liability at one thousand US dollars and permit Oracle to "discontinue the Aconex APIs or any portion or feature… for any reason and at any time without liability." Trimble's developer terms for Viewpoint contain an equivalent clause: "Trimble may impose limits on the number of calls or requests through a Trimble Toolkit for any reason."¹⁰ An integration you build today is one the vendor can throttle or retire tomorrow, on notice terms written entirely in their favour.

Autodesk changed the commercial basis of its APIs in December 2025, moving four of them, including the Model Derivative and Automation APIs, onto a metered token model with a hard enrolment deadline; firms that missed it had their API access suspended until they enrolled.¹¹ Whatever you build against a construction platform's API is built on ground the vendor can move.

Where ISO 19650 actually stands on this question

There is a widely held assumption in UK construction that ISO 19650 requires a single common data environment product, and it is worth correcting directly because it changes how you should think about the whole decision. The UK BIM Framework's own guidance says the opposite: "many solutions exist to deal with different types of project information," and "it is fundamental that workflows are developed first and solutions are selected to facilitate the workflow."¹² Neither the Building Safety Act's golden thread regulations nor the government's Information Management Mandate for major infrastructure names a required CDE product.¹³ The standard was written to be satisfied by more than one tool working together. That gives you real room to decide which functions genuinely need a dedicated platform and which can sit in something simpler, rather than forcing every workflow into whichever single system your main contractor happens to specify.

What actually justifies configuring or building versus accepting the platform as it is

Not every difference between your process and the platform's default is worth fighting. UK government's own Technology Code of Practice states the general principle plainly: "Even small modifications to OTS software can remove most of the benefits of using it," listing higher cost, harder maintenance, reduced ability to scale, and restricted ability to upgrade or remove the customisation later as direct consequences.¹⁴ The National Audit Office's review of shared services found exactly this pattern in practice: services that were "overly customised" and "overly tailored to meet customer needs" ended up costing far more to maintain, and one department ultimately chose to "completely re-implement their system to remove all customisation" rather than keep supporting it.¹⁵

The genuine exception is a process a client or regulator has put in writing that nobody else can supply for you. Network Rail's contractual quality terms state this directly: "Third party registration of assessed capability (i.e., approval to ISO 9001) does not demonstrate that the specified QMS requirements under this contract have been achieved."¹⁶ Where a client mandates its own inspection and test plan format, or its own change control record, that is not a nice-to-have configuration. It is a contractual requirement the standard platform genuinely will not satisfy out of the box, and it is worth the cost of configuring or connecting for.

The test worth applying before any customisation request is simple: is this a contractual or regulatory obligation that is genuinely yours, or is it a habit from the last system that a fresh platform's own default workflow would serve just as well. The first justifies the limited configuration surface these platforms actually offer, or the narrower integration work their APIs actually support. The second is usually cheaper to change than to fight.

Related reading

The same buy-versus-build question sits behind one platform or build your own, and if the platform you are trying to connect is Microsoft 365 specifically, see how to get Microsoft to talk to your platforms. Teams that ended up building their own tooling after hitting exactly these configuration limits have written up what it actually taught them in what building our own tools taught us.

Where to check this yourself

• "What does the UK BIM Framework actually require of a common data environment?" The framework's own free guidance, including Part C on facilitating a CDE, is published at ukbimframework.org.
• "What does UK government guidance say about buying versus customising software?" The Technology Code of Practice's purchasing guidance is free at gov.uk.
• "What quality management standards apply to a construction project?" Network Rail's own quality terms are one worked example, free to read, at networkrail.co.uk.
• "What UK-wide guidance exists for engineers on digital platforms and data?" RICS publishes its professional standards and guidance library at rics.org.

What could not be established for this guide

No independent, methodologically published figure exists for how many separate construction management systems the typical UK contractor runs, and every widely circulated number traces back to a vendor with software to sell. Asite's own API technical limits, beyond its marketing claims, sit behind a gated developer guide this research could not access, so its AppBuilder capability is reported here as a claim to verify with the vendor directly, not as a specification. And no UK court or tribunal decision was found that tests whether the Unfair Contract Terms Act's carve-out for intellectual property rights applies to a software licence, which leaves genuinely open how much legal protection a construction firm actually has against an unreasonable platform contract term.