AI for Engineering Knowledge Management
What a Salesforce-native PLM exposes to an AI agent: Propel's reachable record layer, the file indexing ceilings behind it, and the CAD gap no limit describes.
·
⏱
8 min read
Dr. Maor Farid
Maor Farid is the Co-Founder and CEO of Leo AI, the first AI platform purpose-built for mechanical engineers. He holds a PhD in Mechanical Engineering and completed postdoctoral research at MIT as a Fulbright fellow. A Forbes 30 Under 30 honoree and former AI researcher and Mechanical Engineer in an elite military intelligence, Maor leads Leo AI's mission to transform how engineering teams design better products faster.
BOTTOM LINE
Propel being built on Salesforce makes its structured product data genuinely reachable. Bulk allocations run to 150,000,000 records per 24 hours, permissions and audit come from the platform, and the ceilings are published rather than discovered. That half of an AI project is straightforward. The other half is not. Files are stored up to 2 GB but indexed only to 25 MB for documents and 5 MB for spreadsheets, only the first 1,000,000 characters of any file are searched, and native CAD has no text parser at all. Evaluate any tool on what it does with the second half, because the first half is the platform's work rather than the vendor's.
Most PLM evaluations start with a feature grid. That is the wrong first question when you are choosing an AI tool to sit on top of the system, because an assistant does not use features. It uses whatever the platform will hand back through an interface, at the volume and fidelity the platform allows.
Propel is interesting here because it is built on the Salesforce platform. Its items, bills of materials, change orders and documents are Salesforce records, which means the read path is the documented Salesforce read path rather than a vendor-specific one. That makes a large part of a Propel tenant unusually reachable. It also makes the boundary unusually easy to locate, and the boundary is where most AI projects quietly fail.
This post walks the reachable half, then the half that is not, using the published platform limits rather than marketing claims.
What Running on Salesforce Actually Changes
Propel describes itself as a cloud-native PLM built on Salesforce, sharing one platform with its quality and product information products. For an assistant, that single architectural fact decides almost everything downstream.
When a PLM is built on Salesforce, its business objects are platform objects. An item, a bill of materials line, an engineering change order and an attached document are records in the same store that any Salesforce client already knows how to query. There is no proprietary query dialect to reverse engineer and no middleware tier that has to be licensed before a tool can read anything. The platform's own query language and its REST and Bulk interfaces are the interface.
Three consequences matter when you evaluate tools:
Permissions are inherited, not reimplemented. Sharing rules, field-level security and record ownership apply to an API session exactly as they apply to a browser session. An assistant that authenticates as a user cannot read what that user could not open, which is the correct default and a question you should still ask any vendor to demonstrate.
Audit behavior is inherited too. Reads and writes land in the same audit surface as the rest of the tenant, so a retrieval tool does not create a blind spot beside the system of record.
The limits are published. You can size a project against documented numbers before a pilot instead of discovering a ceiling during one.
That last point separates Propel from systems where the integration surface is negotiated per deployment. The evaluation questions are the same ones worth asking of any platform, and the framework for evaluating an AI tool against a PLM applies here with better documentation than most.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
The Read Path: How Much an Agent Can Pull
Structured product data in a Salesforce-native PLM is, for practical purposes, fully reachable. The published platform allocations are generous enough that record volume is rarely the binding constraint for an engineering tenant.
Salesforce documents a Bulk API 2.0 allocation of 150,000,000 records per 24 hours. A single bulk job accepts up to 150 MB, with roughly 100 MB of actual data once base64 encoding overhead is accounted for. Individual records may carry up to 400,000 characters, and a single field up to 131,072 characters.
Synchronous interfaces are allocated separately. Enterprise and Professional tenants receive 100,000 calls per 24 hours plus 1,000 per Salesforce license, while Unlimited and Performance tenants receive 5,000 per license. A full sandbox is allocated 5,000,000 calls. Requests that run 20 seconds or longer are capped at 25 concurrent in production, and 5 in developer and trial orgs.
Put against a real tenant, those numbers mean an assistant can hold the entire structured corpus in view. Every released item, every BOM level, every change order and its approval chain, every approved manufacturer entry, refreshed as often as the work requires. Questions that depend on traversing structured relationships are answerable with high confidence:
Which released assemblies consume a part that a supplier has put on end-of-life notice, and which of them are in flight on an open change.
Which changes in the last two quarters touched a given subsystem, who approved them, and how long each sat in review.
Where an approved vendor appears on one assembly's manufacturer list but not on a functionally identical part elsewhere.
This is the same shape of reach described for an agent working inside Oracle Agile, arrived at through a far shorter path.
Where the Reach Stops: Files, Not Records
The boundary is not in the record layer. It is in the files attached to those records, and it is wider than most evaluations assume because two different limits are easy to confuse.
The first is a storage limit, and it is permissive. Uploading through a multipart request, a ContentVersion record accepts files up to 2 GB. Other standard objects such as Document and Attachment accept up to 500 MB. Without multipart formatting the request is held to 50 MB of text data, or 37.5 MB once base64 encoded.
The second is an indexing limit, and it is far tighter. Salesforce searches only the first 1,000,000 characters of a document's text, and it applies a maximum size per format before a file is indexed at all. PDF, Word and PowerPoint files are indexed up to 25 MB. Spreadsheets are indexed up to 5 MB or 100,000 cells, whichever comes first. HTML, RTF, plain text and XML are indexed up to 5 MB.
Read those two limits together and the gap is stark. A 300 MB qualification report uploads without complaint, is stored safely, is versioned correctly, and is not searchable by its contents. The platform always indexes the file name, description, type and owner, so the document appears to be findable. Only its metadata is.
This is the failure mode that makes teams distrust a search tool. The file is present, the system returns it when you type its name, and the paragraph inside it that records why a tolerance was opened up stays invisible. That buried reasoning is exactly the institutional knowledge that leaves with the engineer who wrote it.
The CAD Gap That No Platform Limit Describes
The file size ceilings at least appear in a table. The larger gap does not, because it is an absence rather than a number.
The supported formats for document text search are HTML, PDF, PowerPoint, RTF, plain text, Word, Excel and XML. Native CAD is not on that list. There is no parser for a part or assembly file, and none for the neutral formats either. A STEP file, an IGES file, a native part file and a drawing file are all stored faithfully and none of them has a text extractor behind it. For those files the platform indexes the name, the description, the type and the owner, and nothing else.
Propel addresses the handoff with its Design Hub, which the company describes as moving data from ECAD, MCAD and PDM systems into PLM. That is a real capability and it solves a real problem, which is getting structure and metadata across the boundary so that a BOM reflects the design. It is a different problem from making the contents of a model interpretable to a retrieval system. Metadata crosses. Geometry, feature history and the PMI carried on the model do not become searchable text on the other side.
The practical result is a split corpus. The structured half answers questions about what exists and how it changed. The geometric half, where the engineering judgment actually lives, answers nothing on its own. Teams run into the same split when they connect product data to the systems downstream of it, and it is the reason a PLM-only assistant plateaus quickly.
What an Intelligence Layer Has to Add on Top
The conclusion is not that a Salesforce-native PLM is a poor foundation. It is close to the opposite. Propel exposes more structured product data more cleanly than most systems an engineering team will be asked to work with, and the published limits make a pilot easy to size honestly.
What it means is that the assistant has to be built to span the gap rather than to sit inside it. That is the design Leo takes: an AI intelligence layer on top of existing PDM and PLM, not a replacement for either. Leo offers integrations with leading PDM and PLM platforms, including SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM and others, and connects to the rest of an organization's knowledge base, covering local and network directories and ERP alongside the PLM itself.
Three capabilities decide whether that layer is worth deploying. The first is geometry-aware retrieval, so a model is findable by what it is rather than by what someone named it, which is what turns part reuse into something an engineer does by default. The second is reading the documents the platform stores but does not index, so a 300 MB report is as answerable as a record field. The third is citation. Leo is trained on more than one million pages of standards, books and articles, and returns a source an engineer can open and check, which is the only basis on which a specialist will trust an answer about a tolerance or a material property.
The security posture has to carry across the same boundary. Leo is SOC-2 certified and GDPR compliant, no AI is trained on customer data, and intellectual property stays protected.
FAQ
See Leo read what your PLM stores
A walkthrough on your own product data, with a citation on every answer.
Bring a released assembly and a report attached to it. We will show what a retrieval layer returns from a file your PLM stores but never indexed, and where it came from.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
