Concrete setup methods
This guide explains the concrete delivery methods a buyer and a seller can use for workflow setup on FlowMarket. The method must be chosen before work starts, because access, responsibility, testing and delivery proof are not the same in every case.
A setup offer should say exactly how the seller will work: direct access, guided call, buyer-side configuration, sandbox delivery or self-hosted technical setup.
Who touches the n8n instance, credentials and external tools.
What data is used and what result proves that setup is complete.
What the buyer receives after setup: workflow, notes, screenshots or call recording.
No ambiguity
A seller should not write "setup included" without saying how setup will be done. The buyer must know whether the seller will access their n8n account, guide them on a call, deliver a configured sandbox workflow, or only review buyer-side configuration.
Decision table
Use this table to decide how setup should be delivered. Sellers can copy these labels directly into their FlowMarket offer.
| Method | Best for | Buyer provides | Seller delivers | Not suitable when |
|---|---|---|---|---|
| Temporary n8n access | Most standard n8n Cloud setups and simple business automations. | Guest access, required app permissions, test data, expected output. | Configured workflow inside buyer's n8n instance, test execution, delivery note. | The buyer cannot create a limited user or revoke access after delivery. |
| Guided screen-share setup | Buyers who do not want to share access but can join a call. | Computer access, logged-in tools, credentials entered by the buyer, test data. | Live guidance, configuration instructions, real-time checks, final test. | The setup requires long debugging or several disconnected tools. |
| Buyer-side setup with seller review | Technical buyers who can configure credentials themselves. | Self-configuration, screenshots/logs, test results, answers to seller questions. | Checklist, mapping instructions, review, correction guidance. | The buyer expects the seller to touch their environment directly. |
| Sandbox or staging setup | Workflows that should not be built directly in production. | Sandbox access or dummy data, fake credentials when possible, validation rules. | Configured workflow in a test space, exportable final workflow, migration notes. | The final workflow cannot be tested without production credentials or real data. |
| Self-hosted technical setup | Advanced buyers using Docker, VPS, custom domains, private APIs or internal databases. | n8n version, hosting details, logs, env vars required, limited server/admin access if agreed. | Workflow setup plus technical configuration that was explicitly included. | The seller's offer excludes server, DNS, Docker, reverse proxy or hosting work. |
Method 1
This is the cleanest method for many standard setups. The seller configures the workflow directly inside the buyer's n8n instance using limited, temporary access.
Recommended for n8n Cloud, simple self-hosted instances, and workflows using common apps like Gmail, Slack, Notion, Airtable, HubSpot, Sheets, Stripe or HTTP APIs.
Method 2
The buyer keeps control of the accounts. The seller tells the buyer exactly what to click, what to paste and what to test. This is useful when the buyer does not want to grant account access.
Best when credentials are sensitive, when OAuth must be completed by the account owner, or when company rules prevent external access.
Method 3
The seller does not access the buyer's environment. The seller provides exact instructions, then reviews screenshots, logs or exported workflow data sent by the buyer.
Best for technical buyers, agencies, internal teams and companies that do not allow external users into their automation stack.
Method 4
The workflow is configured and tested in a safe environment before being moved to production. This avoids breaking live automations, sending real emails, charging real payments or modifying real data during setup.
Recommended when the workflow touches customers, payments, CRMs, email sending, databases, stock, support tickets or production business data.
Method 5
This method is for buyers running n8n on their own infrastructure. It may involve Docker, environment variables, reverse proxy settings, webhook URLs, firewall rules, databases or private APIs. It must be priced and scoped separately from basic setup.
Only use this method when the seller explicitly accepts self-hosted support. Basic setup should not silently include server administration.
Mandatory before work starts
Without these details, the seller cannot reliably deliver setup and the buyer cannot fairly validate the result.
Security rules
These practices create unnecessary risk for the buyer and the seller. They should not be treated as normal setup delivery.
Seller copy
Sellers can use this text to make their setup offer precise.
Setup method: Temporary access to your n8n instance.
I will import the workflow, configure listed credentials, replace placeholder values, map the agreed fields, run one test scenario and deliver proof of successful execution.
Required from buyer: temporary n8n access, required app permissions, test data and expected output.
Not included: new features, major workflow redesign, server fixes, third-party subscription costs or long-term maintenance.Setup method: Live guided setup call.
You keep control of your accounts. During the call, I guide you through importing the workflow, creating credentials, mapping fields and running the final test.
Required from buyer: access to n8n and connected tools during the call, ability to enter credentials, test data and expected output.
Not included: configuration outside the call, unrelated debugging, custom development or maintenance.Validation
Setup is delivered only when the agreed method has been followed and the agreed test has passed. A vague "it should work now" is not enough.
FAQ
For most simple workflows, use temporary n8n access. It is faster and easier to validate. If the buyer cannot grant access, use guided screen-share setup or buyer-side setup with seller review.
No. The seller should use temporary users, OAuth approval, service accounts, limited API keys, screen-share guidance or sandbox access. Primary passwords should not be shared.
No, not automatically. Self-hosted setup can require server, Docker, DNS, proxy, environment variable or webhook debugging. The seller must explicitly include that work or quote it separately.
Sometimes. The seller can prepare the workflow in sandbox mode or with dummy values, but final validation usually requires the buyer to connect real credentials or run a real test themselves.
That is not basic setup. It should be handled as an extra revision, custom workflow work or a separate quote unless the seller already included it in the setup offer.
Make setup predictable
A good setup offer tells the buyer exactly how the work will happen, what access is needed, what test will prove delivery and what is excluded from the price.