By: Fluw editorial team
Published: September 5, 2026
Integration starts with a user outcome
“We need to connect our CRM” is a useful starting sentence, but it is not yet a plan. A website may need to show stock, accept a request, display an account-specific price, or let a customer check an order status. Each outcome needs a different data set, permission model, and refresh rule. Sometimes a live connection is the right answer. Sometimes a controlled file import is safer and more useful for the first version.
Fluw helps companies assemble websites, catalogs, client portals, and internal web services using company materials and data. The accounting or CRM system remains the source of truth. Fluw does not replace that system or present an unverified connector as ready. Start by defining what a person should be able to do, which fields are required, and where responsibility ends.
Five signs that a connection may be worthwhile
1. The data changes faster than the website
When price, availability, or order status changes every day, manual copying becomes a process of its own. One wrong number can create an incorrect promise to a buyer. A connection is worth assessing when the website needs an agreed field set at a defined refresh frequency.
2. The same object appears in several channels
Products may live in an accounting system, on the website, and in an internal sales view. If a team edits the same name and price in three places, there is no clear source of truth. A connection can leave ownership of the data where it already belongs while the website receives only approved fields.
3. A form must trigger a managed next step
A quote request or customer enquiry should not disappear into an inbox when an owner, status, or history matters. It may be worth assessing delivery to a CRM or another agreed channel. A form on its own is enough only when the team has a reliable way to handle what happens next.
4. The customer needs a personal context
A client portal may show documents, statuses, available products, or previous requests. The website then needs to identify the user safely and retrieve only that user’s data. This is stricter than a public catalog: roles, fields, access duration, and the fallback when the source is unavailable must be agreed in advance.
5. Repetition has become more expensive than an assessment
Count how often people export a file, reconcile a price, move a request, or answer a status question. If the repeated work is a noticeable part of the week, a technical assessment may be worthwhile even before a new channel launches.
When a file is better than an integration
A file is not a fake solution. CSV or a spreadsheet can be the right first step when the catalog is small, updates are infrequent, or the team is testing a new service. It lets you agree on fields, cards, filters, and the request path using test data before touching a production system.
An import is often enough when:
- the first goal is to show an assortment, not promise live availability;
- prices change on a schedule the team can control;
- the website accepts a request but should not create an order automatically;
- the source has no suitable API or access is not approved yet;
- the team wants to test demand before committing to an integration.
Provide a sample file with only the fields the page needs: an identifier, name, description, price, availability, category, image, or document link. Record the export date. A buyer and a manager should be able to tell that the data may not be real-time.
Once the structure and demand are clear, assess the exchange. Do not build a complex integration simply to prove that it is technically possible.
What to check before connecting a system
API and limits
Find out whether the system has documented APIs, which operations they expose, and how requests are limited. “Can we fetch products?” is not enough. Can you request the fields you need, filter records, and understand an error? Refresh frequency should match the website’s real job, not a vague promise of “sync.”
Permissions and data scope
Access should cover only the required read or write actions. A catalog may need products, prices, and availability. A portal may additionally need customer identity, documents, and statuses. Sending a request may require a separate permission. Do not give a website access to the entire database when the page needs three types of data.
Field meaning and mapping
The same label can mean different things. Is “stock” available stock, a warehouse total, or a number after reservations? Is “price” retail, contract, or tax-exclusive? Create a mapping table with the source field, website field, format, required status, and empty-value rule. This turns a technical conversation into a result you can verify.
Direction of exchange
Reading data and writing data have different risks. For a first release, reading a catalog while a manager handles requests in the primary system may be enough. Writing an order, changing a status, or sending a document needs separate agreement, duplicate protection, and an understandable error log.
Freshness and fallback
Decide what a person sees when the source is unavailable or late. You might show the last checked state with its timestamp, hide availability, or move the user to a request form. Do not quietly show an old price as current. Refresh frequency and failure behavior belong in the plan before launch.
Example: an equipment catalog
Imagine a company selling pumps and taking selection requests. The first website version needs filters, product cards, and a request form. A table can reveal which attributes matter to buyers: flow, head, working medium, and material. A manager receives the request manually and checks commercial terms in the primary system.
As requests grow, the team can assess a connection: which fields are readable, how available stock differs from reserved stock, and where a request should go. The website still receives only approved fields. A demonstration showing a source, field mapping, and resulting card is available in the connected catalog example. It shows a structure and test data, not a promise of a ready connector for every system.
For the broader product flow, see how Fluw works. The integrations page explains verified capabilities and boundaries. If access includes customer or document data, review the project’s security approach. For the current commercial context, see pricing.
A pre-decision checklist
- What should the visitor do that requires source data?
- Which exact fields does the page or portal need?
- Where is the source of truth for price, availability, customer, and status?
- Is this read-only, or must it also write a request or order?
- Is there documented API access and a test environment?
- Which permissions, limits, and response formats apply?
- How fresh must the data be?
- What should the user see during a delay or outage?
- Can a file import test the need first?
- Who accepts the result and revokes access when the project ends?
Common failure modes
Connecting a system for its own sake. The page has no clear action, but now carries extra data and maintenance. Start with the user outcome and the smallest useful field set.
Synchronizing everything at once. More fields do not make a solution safer. They make permissions, mapping, and error handling harder. Pick one flow and expand after it works.
Treating availability as a simple number. Reservations, multiple warehouses, and delays change what stock means. Agree on the business rule or the card may look precise while misleading buyers.
Forgetting writes. Sending a request to a CRM can create a duplicate or lose ownership. Agree on an identifier, receipt confirmation, and retry behavior first.
Hiding freshness. If the source updates once a day, the team and the user should know. A clear export date is more trustworthy than “live” without evidence.
Frequently asked questions
Do we need a CRM before we start?
No. You can start with a file and a field description. If a system exchange becomes necessary, check its API, permissions, limits, and data scope first.
Can you connect our accounting system or CRM?
That depends on the specific system, version, access, and required flow. A product name alone does not mean a ready connector. A connection is ready only after its capabilities and boundaries are verified.
Do we have to expose all company data?
No. A good connection limits access to the website’s job—for example, approved products and prices rather than the entire customer database. Agree on fields and permissions before sharing access.
What if there is no API?
Check whether a scheduled export, file, or another approved channel is available. That may be enough for a first version. New automation needs its own technical assessment.
Who owns the price when the source fails?
Agree on the rule before launch: show the last checked timestamp, hide the sensitive field, or send the visitor to a request flow. The website must not present an old value as new.
Start with the result
Describe what a visitor must do: choose a product, send a request, check a status, or download a document. Then list the minimum data and decide whether a file is enough. If a CRM or accounting connection is needed, assess the API, permissions, fields, direction, refresh rule, and outage behavior. Start with a task in Fluw, and treat the system name as the second question.