Comparison
ManyRows vs Propel PLM
Propel is built on Salesforce, and that single fact decides most of this comparison. If Salesforce already runs your company, Propel's closeness to it is worth a lot. If it does not, you are adopting two systems to get one. ManyRows is standalone, priced in public, shaped by you rather than by a platform admin — and building product content into the same record as the BOM rather than bolting a second catalogue onto the side. It has a serious platform of its own underneath, which is the fair way to read this page: the question is rarely whether the model can be expressed, but who has to build it.
The platform question
| Capability | ManyRows | Propel PLM |
|---|---|---|
| Runs on Salesforce Propel is built on the Salesforce platform. If you already run Salesforce that is a real advantage — shared records, one admin model, familiar reporting. If you do not, it is a second system to adopt alongside the first. | No | Yes |
| Salesforce licences required ManyRows is standalone. There is nothing underneath it to buy, learn or administer. | None | Platform licences |
| Who changes the data model Adding a field in ManyRows is a form. On the Salesforce platform it is object, field, layout and permission-set work — powerful, and usually an admin or a partner rather than the person who needed the field. | You, in the app | Salesforce admin |
| Where your product data lives Which of these you want depends entirely on whether Salesforce is already the centre of your company. | Its own system | Your Salesforce org |
The data model underneath
| Capability | ManyRows | Propel PLM |
|---|---|---|
| Entity types, and base types over them Fabric and Trim are both Materials: a field defined once on the Material base type lands on every member, and a reference pointed at Material accepts either one. A type can belong to several base types at once and carry every set of fields that applies. On the platform the equivalent is object, record type and permission-set work — expressible, and a build each time. | Both, in a form | Objects and record types |
| One field, reused across types, tuned per type Country of Origin is a single field attached to Fabric and to Trim — mandatory on one, optional on the other. It stays one field, so filters, facets and CSV columns line up across types. Custom fields defined per object are separate fields that merely share a name, which is what makes cross-object reporting on them a job in itself. | Yes | Fields per object |
| Derived fields that follow a reference Salesforce formula and roll-up summary fields are genuinely capable, and this is not a gap in Propel. The difference is who declares them and where the ceiling sits: a roll-up summary aggregates children of a master-detail parent, one level down. | Reverse and lookup | Formula and roll-up fields |
| Relationships that carry their own data Both platforms model this the same way — the link is a record with its own fields. Here the relationship type is a first-class catalogue entry with cardinality declared and cycle rejection on self-referencing trees, rather than a junction object plus the conventions your admin remembers. | The link is a record | Junction objects |
| The BOM line is a record you design The junction is a real type, so a line carries whatever the work needs and orders itself by an item-sequence field if you want the 10, 20, 30 convention. An optional role field turns a structure into a formula — primary, co-product, by-product, ingredient — with yield per line and absolute yield derived from it. | Yes | Junction object |
| Rollups that walk a multi-level BOM This is the row where the platform comparison stops being even. Total for mass, longest chain for lead time, earliest date for “what is the soonest expiry anywhere in this build”, and worst case over a flag for “is this whole assembly compliant” — each walking the full depth of the tree, not one level. A component with no value is reported as a gap rather than counted as a zero or a pass. | Four modes | Roll-up summaries |
| Effectivity on two axes at once A record can be valid between two dates and between two build numbers independently, and the structure lens applies both together — so “what was in build 400” is a question the BOM answers, rather than one your date fields imply. | Dates and unit numbers | Custom fields |
| Someone to build the model with you Send a spreadsheet, a spec or an export from whatever you run today and we will turn it into types, fields, base types and BOMs with you. It costs nothing because it is the fastest way for us to find out what the product is missing — which is a different arrangement from a partner whose business is the implementation. It comes with Pro and above, and within reason means a first pass and teaching you to run it, rather than becoming your data team. | Free on Pro and above | Partner-led implementation |
What it is shaped for
| Capability | ManyRows | Propel PLM |
|---|---|---|
| High tech, devices and consumer goods Propel is aimed squarely here, with the commerce and channel story to match. | Works | Purpose-built |
| Apparel, footwear and soft goods Size specs with grading and tolerances, per-season time and action calendars, colourways, mills and factories. | Purpose-built | Not its focus |
| Food, cosmetics and other formulations Percentage recipes with co-products and by-products, yield and absolute yield, and quantities fixed per batch rather than per unit. | Purpose-built | Not its focus |
| A mixed portfolio in one system Both handle several product families. ManyRows does it by letting you define each shape; Propel by configuring the platform underneath. | Yes | Yes |
Product structure
| Capability | ManyRows | Propel PLM |
|---|---|---|
| Multi-level BOM | Yes | Yes |
| Where-used, multi-level | Yes | Yes |
| Approved alternates per line | Yes | Yes |
| Formulas with co-products and by-products Primary, co-product, by-product and ingredient roles, with yield per line and absolute yield derived from it. | Yes | Not its focus |
| Fixed vs variable line quantities A catalyst or setup charge is needed once per batch, not once per unit, and the requirements explosion knows the difference. | Yes | Not its focus |
| Several BOM planes per product A materials BOM and an operations sheet on the same item, authored separately. | Yes | One structure |
| Import a BOM from a CAD or spreadsheet export Drop in the indented CSV your tool exports. Parts match on part number, so re-importing after a design change updates the tree instead of duplicating it. | Built in | Built in |
Change control
| Capability | ManyRows | Propel PLM |
|---|---|---|
| Change requests with a working copy Edit a copy, compare it side by side with what is live, approve it and the whole change applies at once. | Yes | Yes |
| Approver rosters, stages and quorum | Yes | Yes |
| Delegation and departed-approver handover An absence does not jam a change request, and someone leaving does not strand one. | Yes | Yes |
| Immutable revisions with the sign-off manifest | Yes | Yes |
| Several change requests released as one decision Re-spec the part and relabel everything that uses it, approved separately, released together in one transaction. | Yes | Yes |
Quality, channels and cost
| Capability | ManyRows | Propel PLM |
|---|---|---|
| PLM and PIM on the same record Both of us think product development and product content belong together rather than in two systems that sync. The difference is what that costs you: Propel gets it by standing on Salesforce, ManyRows by having one record model to begin with. | By design | Yes |
| Product content out to sales channels Channels, listings and per-channel pricing are in the product and being built out now — on the same record the BOM and the change history hang off, so there is no second catalogue to keep in step. Propel's channel story is further along today; ours does not need a CRM underneath it. | Native, in build | Purpose-built |
| Regulated quality processes (FDA, ISO 13485) ManyRows records tests, dispositions and approvals, but makes no regulatory certification claim. | Not certified | Purpose-built |
| Test rounds with verdicts and dispositions Use as is, rework or scrap, with a concession expiry and an owner and due date for the follow-up. | Yes | Yes |
| Measured values against a spec Every value keeps the limits it was judged against, so tightening a spec later never rewrites last quarter's results. | Yes | Yes |
| Costed BOM with wastage and landed cost Rolled cost, extra cost lines, mixed currencies converted at read, and labelled cost snapshots. | Yes | Yes |
| Lot genealogy and recall trace | Yes | Not its focus |
Cost and control
| Capability | ManyRows | Propel PLM |
|---|---|---|
| Price you can work out yourself And with Propel the platform licences underneath are part of the real number. | Listed on the site | Quoted per seat |
| Self-serve signup | Yes | Through sales |
| Free trial Sign up and be inside the product in a minute, without a call first. Paid plans start after the trial, and every price is listed. | 7 days, no card | Demo via sales |
| Export the whole project and re-import it Schema, records, BOMs, specs, quality history and calendars, as a bundle you can move between projects. | One request | Export tooling |
| Full REST API on every record Not only the record: its revision history, the spec it's judged against, its quality record, its schedule and its material requirements are all readable by an integration. | Included | Included |
| Outbound webhooks when something changes Register a URL and we POST to it the moment a record changes or a governed change is approved — HMAC-signed so you can prove it came from us, retried with backoff if you're down, and every attempt visible in the app. You set it up yourself; there's no middleware in between. | Built in, signed | Platform events |
| Custom development when something is genuinely missing Ask before you assume it is a no. When the gap is something ManyRows should have anyway — a field type, an import format, a calculation, an export — we build it and ship it to everyone, at no charge. On Salesforce almost anything is buildable, which is a genuine strength; it is billed to you, as admin time or a consultancy. It is included from the Pro plan up, and within reason means it has to belong in the product for other customers too — if it does not, you get a straight no rather than a quote. | Free on Pro and above | Admin or partner build |
When Propel is the right answer
If Salesforce is already the centre of your business, Propel is the obvious choice and probably the right one — product data next to the CRM, one admin model, one reporting stack, and a genuinely strong story for pushing product content out to sales channels. ManyRows is for teams who are not standing on that platform and would rather not adopt it to get a PLM.
Questions
- How is ManyRows different from Propel PLM?
- Propel is built on the Salesforce platform, which is the main thing to weigh. If Salesforce is already the centre of your company, that closeness to CRM and commerce is a genuine advantage. ManyRows is standalone with nothing underneath it to license or administer, publishes its pricing, and lets the person who needs a new field add it themselves rather than raising it with a platform admin.
- Do I need Salesforce to use Propel?
- Propel runs on the Salesforce platform, so platform licensing is part of the picture and worth including when you compare total cost. ManyRows has no such dependency.
- Should I choose Propel instead?
- If you already run Salesforce, want product data sitting beside your CRM and commerce, and need audited quality processes for regulated devices, Propel is a strong and coherent choice. ManyRows is the better fit when you are not a Salesforce shop, or when your product is a garment or a formulation rather than an assembly.
- How capable is the underlying data model?
- The PLM is an application built on a general typed content platform, which is why it bends to your product rather than the other way round. Entity types are the concrete things you track — Fabric, Trim, Ingredient, Lot, Sample. Base types group them, so one field definition serves several types and a reference can be pointed at the base type to accept any member. Fields are reused across types with per-type overrides, so the same Country of Origin can be mandatory in one place and optional in another and still filter as one column. Links between records are records themselves, so a relationship carries its own fields. Rollups run in four modes, including earliest-date and worst-case-over-a-flag, and each walks the full depth of a multi-level BOM. Salesforce can express much of this — that is the honest position — but as objects, junctions and roll-up summaries an admin or a partner builds and maintains, and its roll-ups aggregate one level, not a whole tree. And if the modelling is the daunting part, we will do the first pass with you — send a spreadsheet or an export from whatever you run today and we will turn it into types, fields and BOMs — included from Pro up, within reason.
- Does ManyRows do PIM as well as PLM?
- That is where it is heading, and deliberately so. Channels, listings and per-channel pricing are in the product and being built out now, on the same record that carries the BOM, the revisions and the change history — so the catalogue cannot drift from the engineering record, because there is only one record. Propel is further along on channel content today; it gets there by standing on Salesforce, which is a cost as well as a capability.
- Can ManyRows handle recipes and formulations?
- Yes. Formulas carry primary, co-product and by-product outputs alongside ingredients, with yield and absolute yield per line, and quantities that can be fixed per batch rather than scaling per unit — so a catalyst is not overstated when the batch grows.
- What if ManyRows does not do something we need?
- Ask us — we do custom development for free on the Pro plan and above, within reason. If the gap is something ManyRows should have anyway, we build it and ship it to every customer rather than leaving it in a private branch for you. That is exactly why it costs nothing: your gap makes the product better. It is also the limit — we will not build a one-off that only you would ever use, and we will not promise a date we cannot hold. The Salesforce platform will let you build almost anything too; the difference is that there the bill lands on you, as admin time or a partner engagement.
- How does this connect to our ERP?
- Two ways, and you can use both. Pull: a REST API over records, BOMs, revisions, quality records, specs and schedules, authenticated with a project API key. Push: outbound webhooks, so your ERP hears about a change when it happens instead of polling for it — signed, retried, and with a delivery log you can check. Neither needs an integration platform in between.