Software companies
Customer-built workflows, templates and configurations: who owns them?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Who owns SaaS configuration data depends on the contract, but most agreements follow a three-way split. The customer owns its content, configurations it builds from that content usually count as customer data, and the vendor keeps the platform, stock templates and reusable product features. Bespoke work by your services team follows the statement of work.
Key takeaways
- Customer content, customer configuration and the vendor platform are three ownership layers that contracts treat differently.
- Broad customer data definitions usually sweep in the workflow rules, custom fields and report definitions a customer builds.
- Bespoke services work belongs to whoever the statement of work names; without an assignment, code your employees write generally stays with your company.
- Turning one customer's workflow into a stock template needs permission or genuine abstraction, not a renamed copy.
- Your own records about configurations, such as implementation tickets and product decisions, form a separate and often licensable layer.
The three-way split most SaaS contracts follow#
Most SaaS contracts split ownership into three layers: customer content, customer configuration, and the vendor platform with its stock templates. The first belongs to the customer, the third to the vendor, and the middle layer is where hesitation and disputes usually start.
Two more cases sit beside the split. Bespoke work your professional services team builds for one customer falls outside the subscription terms and follows the statement of work, and templates customers publish to a marketplace or community follow their own contribution terms.
| Layer | Examples | Usual owner | What decides it |
|---|---|---|---|
| Customer content | Records, uploaded files, messages, notes | Customer | Customer data definition in the subscription agreement |
| Customer configuration | Custom fields, workflow rules, approval chains, report definitions, form layouts | Usually the customer | Customer data definition and any configuration clause |
| Vendor platform and stock templates | Code, schema, default workflows, template library, configuration engine | Vendor | IP ownership clause and reservation of rights |
| Bespoke services work | Custom scripts, integrations and migration tools built for one customer | Varies | Statement of work and deliverables clause |
| Shared community templates | Templates customers publish for other customers | Contributor, with a license to the vendor | Marketplace or community contribution terms |
Why customer configurations usually count as customer data#
Customer configurations usually count as customer data because most subscription agreements define customer data as anything the customer submits to or creates in the service. Intercom's Terms of Service, for example, define customer data as any data, content or other information submitted to the services by or on behalf of the customer.
Under a definition like that, an approval chain or custom field set built by a customer admin is hard to classify as anything else. Configurations also carry business knowledge, such as pricing thresholds, escalation routes, inspection steps and naming conventions, which brings confidentiality clauses into play as well.
What the vendor can usually keep is the general insight. Seeing that many customers build the same approval step is product learning, and many agreements let vendors use aggregated usage data to improve the service. Whether that extends to licensing aggregates outside the company depends on the exact clause, so read it rather than assuming.
Who owns bespoke work your services team built?#
Bespoke work your services team built belongs to whoever the statement of work assigns it to, and without an assignment the default often favors the vendor. Under US copyright law, a work an employee prepares within the scope of employment is a work made for hire, and the employer is treated as the author and owns the copyright unless the parties agree otherwise in a signed writing.
A commissioned work counts as work made for hire for the commissioning party only in certain statutory categories and only with an express written agreement, so custom code for a customer generally needs an explicit assignment to transfer. Many services contracts assign named deliverables to the customer while the vendor keeps pre-existing materials, tools and know-how, licensed to the customer for its own use.
Check old statements of work before reusing anything. A connector built under an assignment clause cannot quietly become a product feature, while a template built under a license-back clause may already be yours. This is general information; confirm the position on specific contracts with counsel.
Turning a customer's workflow into a stock template#
Turning a customer's workflow into a stock template is safe only with the customer's permission or after abstracting it until nothing customer-specific remains. Copying an approval chain, renaming the fields and shipping it to every account can breach confidentiality even when the configuration looks ordinary.
A short internal procedure prevents most problems and leaves a record you can show a customer, an acquirer or a data buyer later.
- Remove customer names, product names, thresholds, price points and internal role titles.
- Rebuild the template from the general pattern, not from an export of the customer's configuration.
- Ask the customer in writing when the workflow is distinctive enough that they would recognize it.
- Record who approved each stock template and what it was derived from.
- Keep contributed community templates under their contribution terms, separate from the stock library.
Which configuration-related records are yours?#
Configuration-related records that are yours include the implementation and support history your team creates while helping customers set up the product. Implementation plans, configuration tickets, solution design notes, escalation threads and the product decisions that turned common requests into features are company records, even when they mention customer settings.
These records often capture the expert reasoning AI developers look for: why a rule was built one way, what broke, and how it was fixed. They need preparation before any reuse, because tickets quote customer field names, screenshots show customer records and notes name customer staff.
| Record | Owner | Before any reuse |
|---|---|---|
| Customer workflow definitions | Customer | Generally excluded |
| Implementation plans and design notes | Vendor | Remove customer names and confidential settings |
| Configuration support tickets | Vendor, with customer content inside | Remove screenshots, field values and personal data |
| Feature requests and product decisions | Vendor | Remove customer identities where quoted |
| Stock template library and change history | Vendor | Confirm no customer-derived templates lack approval |
Illustrative example: a quality software vendor sorts its templates#
Illustrative: a fictional vendor of quality management software for food manufacturers hosts customer-built inspection checklists, corrective action workflows and supplier audit forms. Its stock library ships default templates, and its implementation team has built custom checklists for many plants over the years.
When the CEO asks whether the company's records could support an AI licensing project, the general counsel sorts them into layers. Customer checklists and corrective action records stay out. Stock templates and their change history are company records. Implementation tickets and design notes are company records that need customer names, plant details and photos removed.
One stock template turns out to be a near copy of a large customer's audit form. The company asks that customer for approval, rebuilds the template from the general pattern when the customer declines, and documents the decision. The licensing review then proceeds on implementation and support records only.
How SourceX separates configuration layers#
SourceX applies the same layering when it reviews rights, the second stage of the SourceX five-step transaction. Customer content and customer-built configurations are generally treated as customer data and left out unless contracts and customers clearly allow otherwise, while a vendor's implementation records, support history and product decisions are assessed as company records.
Where a package proceeds, the rights analysis and any customer approvals are recorded in the SourceX Evidence Packet. The SourceX Enterprise Data Value Framework then rates the records on drivers such as domain expertise, human-generated signal and rights, so clean layer sorting directly supports value.
Frequently asked questions
If a customer leaves, do they get their configuration back?
Usually they get customer data back under the export and return clause, and configurations often fall within that definition. In practice configurations may not run in another product, so vendors typically export them as structured files or documentation. State what is exported at termination in the subscription terms so departing customers know what to expect.
Does an implementation partner own the configurations it builds?
That depends on the partner agreement and the partner's own contract with the customer. Partners often assign customer-specific deliverables to the customer and keep their accelerators and templates. If partners build templates on your platform, your partner program terms should say who owns them and what license you receive.
Are custom field names and labels sensitive?
They can be. Field labels rarely contain personal data, but they can reveal confidential business information such as product lines, pricing tiers, internal programs or regulatory problems. Treat customer field names like other customer content during preparation, and replace them with neutral placeholders where they appear in tickets or notes.
Can aggregated configuration patterns be licensed?
Sometimes, if the usage data clause covers it and the aggregates cannot be traced back to a customer. A statistic about how many approval steps typical workflows use is very different from exported workflow definitions. Read the clause closely, consider whether customers would be surprised, and get counsel's view before treating aggregates as licensable.
Should our subscription agreement say who owns configurations?
Yes. One sentence classifying customer-built configurations as customer data, and stock templates and platform features as vendor property, removes most ambiguity. Add language on aggregated usage data and on templates derived from customer work, and keep your statement of work template consistent so services deliverables never contradict the subscription terms.
Sources
- Intercom's Terms of Service (effective April 9, 2025) define 'Customer Data' as any data, content or other information submitted to the Services by or on behalf of the Customer. The definition includes data about People, such as chat and message logs, collected from the Customer Properties through the Services. Source
- Copyright Office Circular 30 explains a work made for hire arises either when an employee creates the work as part of regular duties, or when a work in certain statutory categories is created under an express written agreement with a party specially ordering or commissioning it, and in either case the employer or commissioning party is considered the author and copyright owner. Source
- 17 U.S.C. 201(b) provides that in the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.