👤 For process owners, super admins and company admins
🔐 Available on all plans
🎯 For people organizing incoming customer and supplier requests
A supplier finds two links in separate conversations and asks which one to use to update their details. While the team explains where to go, the request has yet to reach the people who handle it. When each new request needs this guidance, part of the service starts before the team even receives the information.
By the end of this article, you will be able to decide when to bring services together in a Portal, connect each option to the team handling it, and check that an external requester can submit a request and understand what happens next.
What you will learn:
When a Portal helps organize incoming requests
A Portal brings forms, guidance and links together in one entry point. It helps when someone needs to choose a service or read instructions before submitting a request.
Imagine a company receiving supplier registration requests, updates to supplier details and questions about payments. Grouping these options lets the company explain what each service is for without expecting suppliers to understand its internal team structure.
If there is just one familiar request to make on a particular occasion, a direct form may be enough. Asking a defined group to update their details, for example, does not automatically require a page with multiple services. To prepare that information collection, see how to receive external data through public forms.
Choose the channel around the task: submitting a known request, choosing a service or reading guidance. This gives you a basis for deciding how much the Portal needs to include before organizing its pages.
Connect each service to the work behind it
Before building the page, decide what happens to each request. The Portal provides the entry point; the start form collects the information; the pipe is the process where the team handles the request, represented by a card.
Map the services with the people administering the Portal and those responsible for handling requests. The table below is a planning example, not a list of fields to create in Pipefy. Its services and data are illustrative.
| Decision | Initial registration | Updating details |
|---|---|---|
| Audience | Supplier registering for the first time | Supplier already registered |
| Portal label | Request registration | Update supplier details |
| Form | The form defined for initial registration | The form defined for updates |
| Destination | Process receiving registrations | Process receiving updates |
| Responsibility | Team reviewing new registrations | Team reviewing changes |
| Required information | Information defined by the registration team | Details the team needs to review the change |
| Response | Channel and next action agreed with the team | Channel and next action agreed with the team |
For each service, also record who receives the request and which information they need to begin reviewing it. Agree on the response channel with the team responsible, and state a timeframe only if the operation has already defined one.
If “Update supplier details” does not yet have a form, a destination and someone responsible for handling it, settle those decisions before making the option available. The service label should describe work the team is ready to deliver.
Organize pages around the requester
Use names that explain the task. “Submit registration documents” helps a supplier recognize where to go. An internal department abbreviation may need another explanation.
Each option should explain when to use it and what to prepare. If initial registration and updating details are separate services, make the distinction clear. List documents only when the company's actual process requires them.
Create separate pages when audiences or groups of services have different needs. A supplier area may need its own guidance, while a customer area groups support and account updates. If the same audience uses just a few options, one clearly organized page may be enough.
When creating pages, check how they will appear in navigation and who will be able to access them. Separating content visually does not, by itself, set access permissions.
Learn more: see how to organize Portal pages and permissions to put your chosen structure into practice.
Check access throughout the journey
Start by defining the intended audience. An entry point available to anyone with the link needs content suitable for that type of sharing. A service intended for a specific audience needs access that matches that intention.
Review the Portal, the service page and the form. Pages can have their own permissions. A private form remains limited to people with access to it, even when included in a shared Portal.
For the supplier updating their details, validation needs to answer three questions: can they open the entry point, find the right option and submit the form? If any step does not match the intended audience, compare the permissions with the people administering the Portal and the form.
Opening the page does not confirm access to the form. Check the journey with access equivalent to the requester's, as well as from the content administrator's view.
To explore this further, read how permission layers work in Pipefy, in Portuguese.
Learn more: the Portal setup and sharing guide covers the administrative procedures.
Plan what happens after submission
A requester needs to know what to do once the form is complete. Should they wait to hear from the team, use an available tracking option or prepare more information? Agree on this guidance with the people handling the request.
Receiving a request and completing its review are separate stages. In the supplier update example, the guidance should reflect what the team actually does after receiving the details, without suggesting that submission confirms the change has been completed.
Tracking depends on the access and experience used in the process. Review how to track requests in Pipefy, in Portuguese and test the journey that applies to your audience before explaining it. Do not assume every Portal visitor will have the same way to check progress.
If people in this process will submit and track requests as guests, share the Academy course Pipefy para Usuários Convidados, in Portuguese. It covers forms and the requester's routine. Learners need to sign in or create an account to start the lessons.
Validate one service before sharing
Choose one audience and one service for the first test. Use fictional data and ask someone with access equivalent to that audience's to follow the journey. Check whether they can:
- Recognize the service without needing an explanation of the labels.
- Understand which information to prepare.
- Access and submit the appropriate form.
- Understand what happens after submission.
Within the operation, confirm that the request reached the expected pipe and that its information is enough to begin handling it. Where a service is restricted, also check with a profile that should not be able to access it.
If choosing the service raises questions, revise the label and description. If access differs from the agreed intention, adjust permissions with the administrators. If the team needs more information to begin, review collection with the people receiving requests.
Once this journey is validated, share the address through the channels your audience uses and decide who keeps services, guidance and links up to date. Repeat the checks whenever a change affects how people submit requests or receive a response.
Before moving on, confirm that you understand:
☐ When a direct form is enough and when to group services in a Portal.
☐ How to connect each service to its form, process and person responsible for handling it.
☐ Why to check access to the Portal, its pages and its forms.
☐ How to validate submission and response guidance with a fictional request.
Ready to review access across your process? → Permissions in Pipefy: understanding access and avoiding common mistakes, in Portuguese
