👤 For process owners and people authorized to configure the pipe
🔐 Field editing is available on all plans; related features depend on your plan and access
🎯 To adapt data collection while accounting for existing records and the ways that data is used
Your team wants to clarify a question or revise the options on a request. It looks like a small change, yet the answer may also guide an approval, appear in a report, or support another team's work. Before changing the question, you need to understand where the information goes.
By the end of this article, you will be able to identify a field's uses, choose how to adapt data collection, and decide what to test before telling the team about the change. Consider a purchasing process: revising “Request type” means looking at both the person submitting an order and the people using that answer to route the work.
📖 What you will understand here:
Define the change before assessing its impact
Start by completing two sentences: “Today, we collect...” and “We need to collect...”. They help you distinguish clearer wording from a change in what the information means.
If “Contact” already asks for an email address, making that explicit in the title may help people understand the question. If the field contains names, phone numbers, and addresses, you need to rethink what you will collect and how to handle earlier records.
That distinction informs the format you need. An existing Short Text field cannot be converted into an Email field. When you need a different type, plan a new field and a transition for the uses of that information.
- Learn more: check the editable properties in Create and edit fields in forms and phases.
To choose a format based on what the information needs to support, see Field types available in Pipefy and when to use each one.
Describe the change in process terms. “We need to distinguish service purchases from material purchases so we can route the review” provides more context than “we need to change the options”.
Find out who uses the information
A field's uses extend beyond data entry. Someone may read the value to make a decision, while a rule may read that answer or write information to the field. Separating reading from writing helps establish what needs to remain available.
Start by checking Field dependencies. The documentation describes coverage for automations and conditionals and recommends checking dependencies before editing.
Treat the dependency view as a starting point. The documentation reviewed does not describe complete coverage of every use. An empty result does not finish the impact assessment.
Also speak with the people maintaining reports, filters, Interfaces, connections, email templates, documents, AI agents, and Pipefy Integrations that use the information. Include the features present in your process and record who owns each use you identify.
In our hypothetical purchasing example, “Request type” determines which quotation questions appear and helps route the request. Revising its options calls for checking both uses, as well as the filters the team uses to track requests.
For more on the relationship between an answer and the questions that follow, see Smart forms with conditional logic.
Complete the checklist before editing
Use the following checklist to record the impact assessment. Check an item when you have a concrete answer. If something does not apply, explain why. If a use is still unclear, investigate before proceeding.
☐ Define the change. What will be different, and why? Record the field name, its location, and what the information will mean after the change.
☐ Account for existing data. Which cards contain earlier values? Establish who needs to consult them and how to interpret older answers alongside new ones.
☐ Review data entry and access. Who supplies the information, and when? Consider required status, validation, and editing in the relevant phases. Confirm that the people doing the work have the necessary access.
☐ Identify the rules. Which automations and conditionals use the field or its options? Record the expected scenario and what needs review in each rule.
☐ Identify readers and writers. If an AI agent or integration is involved, ask its owner whether it reads or updates the field and what needs to change with it.
☐ Review the outputs. Check the reports, filters, Interfaces, connections, and communications identified in your assessment. Does the information still mean the same thing to the people receiving it?
☐ Plan the transition. If you need another field, agree on when to start using it and how to handle cards already in progress. Do not assume that earlier values will transfer automatically.
☐ Plan the tests. List the affected scenarios, expected results, and the person who will check each result. Include a new request and a card containing earlier information.
☐ Agree on implementation. Decide who authorizes the process change, when to apply it, and what to communicate. Also agree on what to do if the tests do not confirm the expected outcome.
🎓 If the review also involves phases and the form, explore adaptation and testing criteria in Template instalado, e agora?, a short Academy course in Portuguese. Starting the course requires signing in or creating an account.
Choose whether to edit replace or archive
Edit when you still need the same information and want to make it clearer. Check that the options and criteria used by people and rules still match what the process expects.
Create another field when the required type changes. In the “Contact” example, moving from free text to Email requires a different field. Decide how to handle earlier records and update the identified uses before ending the previous collection method. Creating the new field alone does not complete the transition.
Archive when collection is ending but the history matters. The field disappears from forms and cards and stops accepting values, while remaining available for reading in the documented features. First replace its references in uses that need to write to it.
Deleting a field also removes its data. Archiving preserves history but does not keep writing enabled. An automation, AI agent, or conditional that needs to modify an archived field requires a replacement.
- Learn more: review the effects and supported reading uses in Archive a field.
Test the workflow before announcing the change
A useful test follows the information through the process. Agree on a controlled setting with the people maintaining it, then observe the affected scenarios while preventing unintended notifications, writes, or real actions.
In the purchasing example, check a new request for each affected option and a card containing an earlier value. Verify that the expected questions appear, routing matches the agreed criteria, and the team can consult the information it needs.
Include operations that read or write to the field wherever they exist. For required status or validation, also consider a case without the expected information. Test using the profile of the person who will perform the task, since the configuration experience may differ from everyday operation.
Record the scenario, expected result, observed result, and decision. If a critical difference remains unresolved, revise the plan before applying the change. A pipe copy or a title change should not be treated as a guarantee that every effect can be reproduced or reversed.
Once the checks are complete, explain what changed, when it takes effect, and how to handle requests already in progress. Testing supports the decision; the record helps the team track its effects in everyday work.
Before moving on, confirm that you understand:
☐ I can distinguish clearer wording from a change in data type or meaning.
☐ I can identify who reads and writes to the field, going beyond the dependency view.
☐ I understand the differences between editing, creating another field, archiving, and deleting.
☐ I have test criteria for new data, earlier records, and affected paths.
Ready to review which questions each person needs to answer? → Smart forms with conditional logic
