👤 For pipe admins and people reviewing how requests enter a process
🔐 Forms are available on all plans. Conditionals require Business, Enterprise, or Unlimited
🎯 For anyone who wants clear criteria for form completion and request receipt
An expense reimbursement request reaches the team, but someone still needs to ask what the expense was for or request a readable receipt. The request has been submitted, yet the review depends on rebuilding the context through separate messages.
By the end of this article, you will know how to choose test scenarios and decide whether your form is ready to receive requests. We will follow a fictional reimbursement example from both sides: the person making the request and the team reviewing it.
Sharing here means making the form available to its intended audience. The focus is the Start Form, which creates a new request in a pipe, including its public version when that is your chosen channel.
📖 What you will understand here:
Define what the team needs to receive
Before entering any test data, ask the person who receives the request: what do you need to know to start working?
For our reimbursement example, imagine that the team needs to identify the expense, check the amount, and review the receipt. These are requirements chosen for this scenario. Your company's process rules determine what matters in your own case.
Use this discussion to separate information needed at intake from information that can be collected later. A piece of information is essential when the next decision cannot proceed without it. Asking for something simply because it might be useful later may require context the requester does not yet have.
Write the expected result as a concrete statement: “When the reimbursement arrives, the team can identify the expense and begin reviewing it without asking for more context.” Use that statement to assess the tests.
A completed field does not prove that the answer is useful. “Other expenses” may fill a description field without explaining what the money was spent on. The test should also check whether the team can work with the answer.
If people outside your team will use the form, see how to prepare a public form to receive data from outside the platform. Use it to review the wording and context provided to someone unfamiliar with the process.
Choose scenarios that change the answers
One completed submission proves only one path. Before sharing more widely, choose situations that change what the person must provide or what the team needs to review.
In our fictional reimbursement process, consider an Expense type field with Travel and Supplies as options. If the company has decided to collect additional information for Travel, test both options. You do not need to add conditionals just for testing: evaluate the paths your process actually uses.
Also try leaving out information marked as required. Observe whether the form guides the person to provide what is needed before completing the submission. This lets you compare the configured requirement with the process need.
When conditionals are present, test the answer that displays a field and the alternative that hides it. Include a change of mind: enter the Travel details, then switch to Supplies. Check both what is displayed and what reaches the request. Do not assume what happens to a value entered before its field becomes hidden.
To review the reasoning behind those choices, read Smart forms with conditional logic.
Conditionals show or hide fields according to defined rules. Only pipe admins can configure them, and they require Business, Enterprise, or Unlimited. Displaying a question does not, by itself, approve a request or move it forward.
🔗 Learn more: review conditional setup and its prerequisites.
Test from the requester's perspective
Invite someone who did not build the form to use it with a defined situation. In the reimbursement example, they could represent an employee who has just returned from a trip and has the receipt ready.
Observe whether they understand the title, can distinguish the options, and know which file to submit. Let them try to finish using the available guidance. If you need to explain a field during the test, record the question and consider which description or example would help the next person.
Access is part of the test too. Use the channel you plan to share and the access profile of the person who will actually make the request. Testing in an admin session does not establish what a supplier or employee with different access will experience.
For a restricted form, check that an authorized person can access it. If the goal is to accept requests through a public version, assess that external experience. A private browser window helps separate the admin session, but it does not replace testing with the intended profile. If your audience usually uses a phone or a form embedded on a website, include that context.
🎓 If your requesters read Portuguese, suggest Pipefy para Usuários Convidados, a Portuguese course covering form completion and request tracking. Academy lessons require login or registration.
Check what the submission produced in the process
Validation continues after submission. Find the card created in the intended pipe and compare the information received with the test answers. Ask the person responsible for intake to check whether they can begin the review.
For reimbursement, that means recognizing the expense type, checking the amount, and opening the receipt when those details are part of the process. An attached file must be useful for review: submitting a document and being able to read the necessary information are separate checks.
Also look at the guidance the requester receives at the end. Can they tell that submission is complete and understand what happens next? Confirmation helps the requester; checking the card establishes receipt for the team.
Submitting a Start Form creates a card. Cards cannot be created from the form editing page. Before a test submission, agree with the process administrator on how to identify the test record and handle any linked communications or actions. Use fictional data.
If intake already triggers rules, check the intended effects for that scenario. Do not expect an email, an assignment, or a phase movement simply because a form was submitted: those outcomes depend on the process design.
- Learn more: understand the difference between editing a form and submitting information to a process.
If the goal is to add information to an existing reimbursement, consider when to use a Phase Form in Pipefy. It collects a contribution connected to the existing card instead of opening a new request.
Decide what to fix before sharing
Compare the expected result with what you observed. Record the difference clearly enough for someone else to understand what needs attention. You can use a table like this in your team's working document.
| Scenario | Expected result | Observed result | Decision |
|---|---|---|---|
| Complete Travel request | Team identifies the expense and reviews the receipt | Data and file support the initial review | Pass this scenario |
| Missing required information | Person is guided to provide what is needed | Person does not know where to find the information | Review guidance or when to collect it |
| Switch from Travel to Supplies | Questions and data match the final choice | Earlier value reaches the team without context | Review path and retest |
The observed results in this table are illustrative. In your own test, record what actually happened and whether the scenario passed or needs adjustment.
Before sharing more widely, resolve anything that prevents the intended audience from accessing the form, completing a submission, or providing what the team needs to work. An access restriction needs adjustment only when it conflicts with the intended audience. A visual improvement can wait if the form is readable and clear to complete.
After a change, repeat the affected scenario and any paths that depend on the same change. If you adjust a Travel conditional, for example, check the Supplies alternative too.
The decision to share should bring together two pieces of evidence: the requester can finish using the available context, and the receiving team can take the next step with the information received.
Choose a form that is nearly ready, agree on scenarios with the people involved, and record the results. To build on request, form, and portal management, continue with the Academy's Pipefy Process Manager Certification. Lessons require login or registration.
Before moving on, confirm that you understand
☐ Tests start with the information needed for the team's next decision.
☐ Different paths and changes of answer also need to be assessed.
☐ Access should be checked using the intended requester profile and channel.
☐ Submission completion should be followed by a check of the card received.
Ready to plan how to collect information after a request has started? → When to use a Phase Form in Pipefy
