Form builder application examples for copier setup intake

The most useful form builder application examples for a signal copier are three short intake forms: one for broker and server details, one for multi-TP split rules, and one for risk-per-trade limits. Each question fills exactly one config field, so a submission turns into a working copier setup without a week of back-and-forth messages on Telegram.

Where the intake form sits in a copier setup

If you set up copiers for clients, the slow part is rarely the install. It is chasing details: which server string the broker uses, whether the account is hedging, what the client wants done when a signal lists three take profits. People answer these in scattered chat messages, and you copy them into a config by hand.

In our Telegram Signal Copier projects, the form comes first. It sits between the sales call and the VPS install. The submission becomes a config file, we install the copier on the client's VPS, run the parser against sample signals on a demo account, then go live with every execution logged. The form decides how much guessing happens in the middle steps.

Start from the client intake template

You can build all three forms in Qwenvo, a form builder our team makes and keeps completely free. If you want a general starting point first, the client intake form guide covers the basic structure.

Form 1: broker and server details

This form fills the connection block. Keep it to what you can verify.

• Platform: a dropdown with MT4 or MT5. It sets platform.
• Broker name and exact server name: two short answers. The server string must match what the terminal shows, so ask for a screenshot of the login dialog using the file upload block. It sets server.
• Account number: a number block. It sets login.
• Account mode: hedging or netting, shown only if the platform is MT5 (use conditional logic to hide it for MT4). It sets account_mode.
• Symbol suffix: a short answer wtih help text such as "Open Market Watch and look at how gold is spelled." Brokers name the same instrument differently, so this sets symbol_suffix and any symbol mapping.

The netting question earns its place. On a netting MT5 account there is one position per symbol, so a signal split across three take profits cannot become three separate positions. Better to learn that from the form than after the first live signal.

One ruule we hold firm on: the form never asks for a trading password. The client enters credentials on the VPS themselves, or we do it together on a screen share. Qwenvo also has a data retention setting that auto-deletes submissions after a number of days, which is worth switching on for anything containing account numbers.

Form 2: multi-TP split rules

Providers post signals like "TP1 2340, TP2 2345, TP3 2352," and the copier needs to know what to do with each level. Clients rarely have an opimion until you ask them plainly.

• TPs to follow: a dropdown from 1 to 4. It sets the length of tp_split.
• Percent per TP: one number per level, shown by conditional logic only up to the count chosen above. A calculated field adds them up so the client sees the total before submitting.
• Move stop loss to breakeven: choose never, after TP1, or after TP2. It sets move_sl_to_be_after.
• If the signal has one TP: put it all on that TP, or skip the trade.
• If the signal has no stop loss: skip, or use a default distance in pips.

Those last two are the cases that cause real trouble in production, and they are easy to fprget when you design the form from the happy path. Check the percentages again in your webhook handler as well. A form is a convenience, not a validator you can trust.

Form 3: risk-per-trade limits

This is the form prop-firm challenge traders care about most, because a challenge can end on a single oversized lot.

• Risk mode: pdrcent of balance, fixed cash amount, or fixed lot. It sets risk.mode.
• Risk value: one question that appears based on the mode. It sets risk.value.
• Max daily loss: a percentage, with help text telling the client to set it below the prop firm's own daily limit. It sets max_daily_loss_pct.
• Max open trades: a number. It sets max_open_trades.
• Max lot size: a hard ceiling that applies even if the risk math suggests more.
• Prop firm account: yes or no, with a follow-up asking for the firm's drawdown rules in a long answer field.

Partial submissions are handy here. If a client drops off at the risk page, you see an incomplete row and know exactly where they stalled. That is usually the question they did not understand, so you can rewrite it.

Field to config map

The result is a config like this (illustrative values):

{
  "client_id": "c_0142",
  "platform": "MT5",
  "server": "ExampleBroker-Live01",
  "login": 5012345,
  "account_mode": "hedging",
  "symbol_suffix": ".m",
  "tp_split": [50, 30, 20],
  "move_sl_to_be_after": "TP1",
  "risk": { "mode": "percent", "vlue": 0.5 },
  "max_daily_loss_pct": 4,
  "max_open_trades": 3
}

Setting it up step by step

1. Build the forms. Start from the intake template, or write the questions in Markdown (# for the title, ## for each question, - for options) and ikport it. Split the three forms across pages of one form if the client is the same person.
2. Add a hidden field for client_id. Send each client a link with their ID in it, so submissions arrive already tied to the right record. The hidden fields help page shows the setup.
3. Point a webhook at your endpoint. Qwenvo sends submissions to any URL, so a small script, Zapier, Make or n8n can all receive them. Map each answer to its config key and reject any submission where tp_split does not total 100.
4. Write the config to a staging folder, not the live one. Someone should read it before it reaches the VPS.
5. Run a demo account first. Replay a few sample signals, including a one-TP signal and one with no stop loss, and confirm the sizing matches the risk fields.
6. Put the form on your own subdomain. Add forms.yourbusiness.com as a custom domain, switch off the Qwenvo badge, and share that link. It looks like part of your service.

Read the webhooks guide

What you get free, and where another tool fits

Custom domains, partial submissions, branding removal, teammates and custom CSS are all free in Qwenvo, along with webhooks, the API, an MCP server, and AI triage with routing. Tally puts several of those, including custom domains, branding removal, teammates and partial submissions, on its Pro plan at $29 a month. If you only need a basic form, Tally's free plan is solid.

One honest caveat: Qwenvo launched in October 2026, so there are few public reviews yet, and it is hosted in the United States. If your clients are in the EU and European hosting matters to them, Tally is hosted in Europe.

After go-live, a fourth small form earns its keep: a change request. Clients send it when they wat a different risk valie or a new symbol suffix. AI triage can tag urgent ones, such as "copier stopped opening trades," and route them to a Slack incoming webhook or up to five email addresses.

Add hidden fields to your form

Questions teams ask

Should the form collect broker passwords?

No. Collect the account number and server name, and have the client enter the password on the VPS directly or during a screen share. Anything the form never receives cannot leak from it.

Can I do this in Google Forms?

You can for the text questions. The catch is the server screenshot: Google Forms requires respondents to sign in with Google to upload files, which adds friction for clients who just want to be done.

Do signal providers need a different form?

Mostly yes. Providers on the provider tier need questions about the channel or room being parsed, the signal format they post, and whether they send images. The split and risk sections can stay the same.

How do clients change their settings later?

Send the same form link with their client_id in the hidden field, or use a short change request form. Either way you get a new submission to diff against the current config instead of an edit buried in chat.

Next step

Open the client intake template, add the broker and server questions from Form 1, and send yourself a test submission through a webhook to a script that prints the mapped config. If the printed config matches what you would have typed by hand, build Forms 2 and 3 the same way.