01
Construction and project management
Projects, RFIs, submittals, documents, commitments, correspondence, and project-team activity.
Procore, Autodesk Construction Cloud, Oracle Aconex, CMiC, and Fieldwire
AEC systems directory
Compare 57 construction, property, enterprise, integration, data, reporting, development, and AI systems through an operating-layer perspective. Each profile separates vendor-supported access from the workflow, authority, validation, and ownership decisions a buyer still has to make.
Use the directory for a system decision
A documented API does not prove that a system should be replaced, that every required record is accessible, or that an agent may act. Start with the workflow, authoritative fields, native identities, permissions, acceptance boundary, and the client’s continuing ownership.
Curated system profiles
The 57 sourced profiles cover common AEC operating systems and the adjacent enterprise, integration, property, data, development, and AI platforms that participate in connected workflows. Each is an implementation-oriented buyer guide, not an endorsement, universal compatibility statement, procurement ranking, or replacement recommendation.
Construction, document, model, estimating, schedule, field-service, financial, reporting, record, and orchestration platforms commonly encountered in AEC delivery.
Automation, CRM, work management, cloud data, analytics, and relational infrastructure that connect AEC work to wider business operations.
Distinct enterprise workspace, developer API, model deployment, research, media, and source-grounded assistance boundaries.
Development, communication, content, ERP, property, geospatial, field, reporting, and work-management systems that may participate in a connected workflow.
Browse by business function
The examples orient buyers to common system roles. A named product is not treated as verified or compatible unless its current product, module, region, deployment, permissions, and required interface are checked.
Projects, RFIs, submittals, documents, commitments, correspondence, and project-team activity.
Procore, Autodesk Construction Cloud, Oracle Aconex, CMiC, and Fieldwire
Takeoffs, pricing, bids, quote requests, estimate versions, assumptions, exclusions, and approvals.
Bluebeam, STACK, and configured estimating tools
Models, drawings, specifications, revisions, markups, transmittals, reviews, and technical records.
Autodesk Revit, ProjectWise, Revizto, Solibri, Newforma, Box, and SharePoint
Customers, vendors, cost codes, commitments, invoices, actual costs, billing, and financial periods.
Sage, Viewpoint, CMiC, NetSuite, Dynamics 365, and Deltek Vantagepoint
Projects, WBS, activities, relationships, calendars, resources, baselines, and controlled updates.
Oracle Primavera P6
Companies, contacts, leads, opportunities, activities, follow-up, pipeline stages, and handover.
Salesforce, HubSpot, Dynamics 365, Airtable, and Teable
Stable identities, linked business records, source crosswalks, workflow states, reviews, and accepted outputs.
Teable, Airtable, PostgreSQL, Snowflake, and Databricks
Governed measures, reporting periods, reconciliation, dashboards, commentary, and source drill-through.
Power BI, Tableau, and Looker
Document libraries, folders, messages, attachments, collaboration, permissions, and retention context.
Microsoft 365, Google Workspace, Slack, Box, Dropbox, and Newforma
Triggers, mappings, deterministic rules, notifications, retries, exceptions, monitoring, and recovery.
n8n, Power Automate, Make, Zapier, UiPath, and Workato
Approved classification, extraction, comparison, retrieval, drafting, and bounded tool use inside controlled workflows.
OpenAI, Anthropic, Gemini, Azure AI, Bedrock, Perplexity, NotebookLM, and ElevenLabs
Properties, assets, tenants, work orders, inspections, vendors, service evidence, billing, and history.
Yardi, MRI Software, ServiceTitan, Fieldwire, and Esri ArcGIS
Keep, connect, contain, consolidate, or reassess
These are buyer decisions reached from workflow evidence, ownership, access, security, support, migration, adoption, and total operating effort. They are not permanent labels applied to products in the directory.
Keep a system when it performs its specialist role, has accountable ownership, and can provide the required information through an approved method.
Connect it when the system remains useful but its records, documents, states, or approved actions must participate in a wider workflow.
Contain it when clean integration is unavailable but exports, controlled browser work, documented handoffs, or review queues can govern its role.
Consider consolidation when overlapping tools create avoidable duplication, conflicting records, unclear ownership, or disproportionate operating effort.
Reassess platform fit when essential security, access, data, workflow, support, portability, or operating requirements cannot be met within an acceptable boundary.
Connected RFQ example
An invitation may begin in email or a portal, documents may sit in a shared folder, pricing may remain in an estimating tool, communication may continue in Outlook, and financial facts may belong elsewhere. The connected record coordinates identity, state, ownership, evidence, and approval without pretending one application owns everything.
Explore the RFQ-to-bid workflowStable RFQ identity
Linked company and project
Controlled document package
Current addendum and revision state
Bid or no-bid owner
Assigned estimator
Quote-request status
Due dates and reminders
Commercial approval boundary
Submission evidence
Outcome and lessons record
Six buyer tests
Two companies using the same product can have different modules, records, permissions, regions, versions, workflows, and integration rights.
Access labels
Every implementation still requires product, edition, environment, licence, region, permission, volume, field, read-write, failure, and ownership verification.
Preserve source-system record IDs and map them to durable operating-layer IDs. Do not require every source to rename its records.
A connected layer can coordinate records while project, finance, schedule, document, and professional systems retain authority for their accepted fields.
Authentication and API access do not grant commercial, contractual, financial, design, engineering, safety, compliance, or release authority.
Systems and integration questions
The same product can be appropriate in one workflow and unsuitable in another because configuration, authority, data, permissions, support, and failure consequences differ.
Usually not. First determine which platforms still perform their specialist roles, which records they should own, and whether approved connections can solve the workflow problem without unnecessary migration.
Potentially. Approved exports, imports, inboxes, folders, database access, secure files, controlled browser workflows, or documented human handoffs may be viable. Each method requires its own authority, monitoring, maintenance, and failure controls.
No. API availability does not resolve incompatible identifiers, missing fields, duplicates, permissions, source authority, workflow states, rate limits, retries, or business approval.
AI may assist with approved retrieval, classification, extraction, comparison, drafting, or bounded tool use. Production access depends on reliable context, permissions, evaluation, monitoring, failure handling, and human authority.
There may be no single system for everything. Authority should be assigned at record or field level, with stable IDs and conflict rules connecting project, finance, schedule, document, workflow, and reporting systems.
Yes. Spreadsheets may remain useful calculation tools, controlled interfaces, import sources, or outputs. Hidden rules, duplicated facts, weak identity, unclear ownership, and uncontrolled copies must be addressed.
Yes, when its role, access method, permissions, support condition, failure path, recovery procedure, and continuing ownership can be controlled. Replacement is not automatic.
No. The directory explains operating fit and documented vendor interfaces. Listing does not constitute endorsement, resale, security certification, procurement advice, or guaranteed compatibility.
A buyer-specific comparison can examine workflow fit, required records, access methods, permissions, migration, ownership, implementation effort, support, portability, and continuing operating cost. It should not become a universal product ranking.
Where included in scope, StructuredLayer documents record models, native-ID crosswalks, field authority, mappings, workflows, permissions, monitoring, exceptions, recovery, training, and maintenance ownership in a client-controlled handover.
Bring one system and one workflow
A buyer assessment should name the system, product or module, workflow, records, source owner, users, access method, required direction, failure consequence, and intended decision.