👤 For process owners, super admins and company admins
🔐 Available on all plans
🎯 For anyone organizing incoming external requests with clear guidance and appropriate access
A supplier needs to submit documents, finds three links in different conversations and asks your team which one to use. A customer wants to update their details and messages the contact they already know. When every request starts with someone asking for directions, your team also has to gather information before it can begin the work.
By the end of this article, you will know when to bring services together in a portal, how to organize choices for people outside your company and what to check so they can send their request to the right process.
📖 What you will learn:
What a portal brings together
A Pipefy portal brings forms, guidance and links into one place. For customers and suppliers, it can serve as a reference for finding where to make a request and what to prepare before submitting it.
Each part serves a purpose: pages organize content; a start form collects the information needed to open a request; and a pipe is the process where your team handles it. Submitting the start form creates a card that represents the request in that process.
This lets you describe services in terms the requester understands, even if your team uses different names internally. A supplier needs to recognize where to submit documents without knowing the stages of your registration process.
For more context on external participation, see the section on collecting information from external users through forms in the Community permissions article, available in Portuguese.
When to bring services into a portal
If someone already knows what they need and there is only one form for that request, sharing the form directly may be enough. A portal becomes useful when people need to choose a service or read guidance before they submit.
Consider an illustrative supplier service scenario. If the only service is initial registration, a form with clear instructions may meet the need. If your company also offers document submission and payment inquiries, bringing those options together helps suppliers choose the right path.
Base that choice on the services your company actually provides. Each option needs a defined process for handling the request. Adding a form to the portal makes it easier to find; your team still needs to decide how to handle what comes in.
💡 Before creating another page, ask whether the person needs to choose a service, read instructions or simply submit a request they already understand. The answer helps you decide how much guidance to provide.
Organize pages around what people need to do
Use names your audience recognizes. “Submit registration documents” describes a task. An internal department code asks suppliers to know something they may never have encountered.
Explain what each option is for. If there are separate forms for initial registration and changes to existing details, describe when to use each one. When people need to prepare documents, list what your actual process requires.
Customers may have different needs from suppliers. In another illustrative scenario, a customer page brings support requests and account detail changes together. Separating it from supplier content lets you provide guidance for each audience. If the same people use a small set of services, one well organized page may be enough.
Portal pages can have different permissions. When deciding how to group content, consider who needs access to each set of information. A page you create needs to be published in the main portal to appear in user navigation, subject to its access settings.
🔗 Learn more: see how to organize portal pages and their permissions to put that structure into practice.
Check access to both the portal and its forms
Start by deciding who should see the content. A page available to anyone with the link needs a different review from one reserved for selected people. Consider what can be published and what information should remain restricted.
Portal and form permissions both need to serve your intended audience. A private form remains available only to people who have access to it, even when it is included in a shared portal.
Suppose a supplier can open the page but cannot find the expected form. Compare the page audience with the form sharing settings in the pipe. To explore the broader access model, read how to understand permission layers in Pipefy, available in Portuguese.
⚠ Opening a portal and accessing a form are separate steps. Before sharing the address, check both using access equivalent to that of the intended requester.
🔗 Learn more: the portal setup and sharing guide explains the options available to administrators.
Plan what happens after submission
The experience continues after someone submits the form. They need to know what to do next: wait for your team to get in touch, track the request through the access available to them or provide more information when asked.
In the supplier example, include guidance that matches how your team responds after receiving documents. State a response time or communication channel only if your company has already defined it.
Request tracking has its own access conditions. Users with the corresponding access can view requests in Tasks & Requests. Plan and test that stage for your audience rather than assuming the portal address gives every visitor the same tracking experience.
🔗 Learn more: see how to make and track requests in Pipefy to guide people within the access context that applies to them.
If people in your process will submit and track requests as guests, share the Academy course Pipefy para Usuários Convidados, available in Portuguese. It covers forms and the requester's routine. Starting the lessons requires signing in or creating an account.
Test the journey with a sample request
Start with one audience and one service. Ask someone with access equivalent to that of your intended audience to go through the journey using fictional data. Check whether they can:
- Recognize the service without asking someone to explain its name.
- Understand what to prepare before completing the form.
- Access and submit the intended form.
- Understand how they will receive a response about the request.
Within the internal process, confirm that the sample request reached the corresponding pipe with the expected information. If choosing a service was unclear, review its name and description. If access needs adjusting, review permissions with the people who administer the portal and form.
After that check, share the address through the channels your audience uses. Assign someone to keep the guidance current when services change.
Before moving on confirm that you understand:
☐ When a direct form link meets the need and when a portal helps bring services together.
☐ Why page and form access must match the intended audience.
☐ How to test request submission and the guidance about what happens next.
Ready to review who can access each part of the process? → Understanding and avoiding common permission issues in Pipefy (article in Portuguese)
