As a best practice, use Collections to maintain your organization's business data as its "source of truth" from which Processes and their Requests read and edit. Do not use Processes, and the Screens in which those Processes access, to store and maintain business data. Collections are designed to maintain business data outside of Requests. There are several advantages to following this best practice:
Request participants may not be business stakeholders, and vice versa: Configure Collections permissions for users or for groups who may view, edit, or delete records in each Collection. These users/groups can have access to business data without participating in Requests. Inversely, those who may change specific information within Collection records may not be business stakeholders to view all information in Collection records.
Business data can exist outside of Requests: Since Collections are the "source of truth" for your organization, this information may exist prior, during, and after Requests exist.
Separate Process design from your business data: By maintaining business data outside of Requests, there is a separation between Process design and the "source of truth" of your information. The Process may change or be archived, but the business data from which Requests access exists outside of those Processes.
Use Requests as an audit log how your business data changes: Maintaining your business data in Collections makes auditing your information easier because there is a digital accounting of how your business data changed via Requests.
As a best practice, use Requests to edit Collection data. Do not edit Collection records directly from within the Collection. By using Requests to edit Collection data, your organization maintains an audit log of your business data via Requests.