Every spec, every material, one source of truth.
Specification data management on Salesforce, implemented by a partner who knows both layers.
Every layer, its attributes and its supplier
Six parts of a working spec program
Requirements and BRDs
Workshops and a written business requirements document, signed off before the build.
Configuration
Objects, fields, formulas, record types, layouts and Lightning pages.
Rollups and hierarchy
Rollup field settings and visual hierarchy, so data adds up across the tree.
Permissions
Per-object read, create and edit, and delete permission sets, with field level security.
Data migration
Specs, materials, BOMs and supplier data out of spreadsheets and legacy systems.
Integrations and exports
ERP and PLM connections, BOM exports and the reports your team needs.
From spreadsheets to specifications
The spec usually exists already. It is just scattered.
Audit, design, build, adopt
We start with a two-week audit, so the build is priced against what is really there.
Audit
Current org, current data and the gaps, documented in two weeks.
Design
A business requirements document your team approves before configuration.
Build
Configured, migrated and tested in a sandbox with your own specs.
Adopt
Training, go-live, then monthly enhancements on a subscription.
What we configure
The objects and settings that decide whether a Specright org is usable a year later.
Specification model
Platform layer
Why spec programs stall
The platform is rarely the problem. The model underneath it is.
What we walk into
- Specs still maintained in parallel spreadsheets
- Hierarchy built once, never rolled up, so reporting is manual
- Everyone has full edit rights, so history is unreliable
- Supplier data typed in twice, once in ERP and once here
- No owner after go-live, so the org drifts
What we put in place
- One specification record both sides work from
- Rollup field settings and visual hierarchy configured properly
- Per-object permission sets with field level security
- Integrations to ERP and PLM instead of double entry
- A named consultant and monthly enhancements
From the spec data practice
What we run into on consolidation, compliance reporting and supplier data work.
EPR reporting turned packaging data into a filing requirement
Seven states took producer reports this year. All of them ask the same questions of your spec data.
Read the articleMerging two specification orgs without losing the compliance record
The packaging hierarchy, the picklists and the archive rules are where a consolidation loses time.
Read the articleThe supplier ingredient request is where product development stalls
What changes when the request becomes a record, and the silent automation failure that costs weeks.
Read the articleFour spec data automations that pay for themselves in a month
Component naming, pallet hi and load cube, unit conversion and the export somebody rebuilds by hand.
Read the articleSend us one product spec
One real spec and how your team maintains it today tells us most of what a build would take.