Use the Collections package to maintain sets of schema-less data, each referred to as a Collection. Each Collection uses up to three different Screens to create, edit and view information in that Collection. Functioning similarly to a database, Collections provide ease and flexibility to design custom data views for information storage and reporting without integrating into an organization's IT infrastructure. Also similar to a database, each Collection contains a set of records, each representing distinct sets of information similarly to how a conventional database contains a set of fields that comprise a record.
Use Collections to store data from which Requests can read and edit record data. Use Collections to manage data outside of your Processes and their Requests. Consider Collection record data as the "source of truth" from which your organization maintains its data. Each Collection record represents the state of particular information. The information that each Collection record contains may need to exist outside of any Process or Request, making them great for business solutions. Consider the following examples:
Employees in a company: Each record is an employee at a company. Each record may contain information such as a company ID and job role, but also the state of onboarding or offboarding each employee.
Patients in a medical office: Each record is a patient in a medical office. Each record may contain personal and health information, but also when each patient's next upcoming appointment is scheduled.
Orders in an e-commerce company: Each record is the state of an e-commerce order. Each record contains the items selected for purchase, the state of payment for that order, shipping information, and relevant discount code.
The Collections package has the following features:
An external database is not required to store Collections. Collections are maintained in the ProcessMaker instance.
A Collection is composed of a set of records. Similar to a relational database, a record is a grouping of fields that represent related data. Design the grouping of fields using Screens to represent this data, thereby making it easy for any user to view, create, or edit record data if they have the appropriate permission(s) to do so. Within a Collection, potentially use different Screens to create a record, edit a record, or view a record within that Collection. This provides greater control in how information within a Collection is consumed by various stakeholders in the Collection. Consider the following use case:
Create a record: Allow an assistant to create a record using Screen for this purpose, such as in a medical practice.
Edit a record: In the same medical practice, a dedicated Screen allows a nurse to edit patient information after the new patient has granted legal permission for medical staff to edit sensitive medical information (in compliance with HIPAA standards).
View a record: Use a third Screen that references identical record information, but limits the content and editing so that the medical practice complies with patient legal protections.
Collections are schema-less, meaning that any type or format of data may be stored in a Collection. Because Collections are schema-less, changing the Screen(s) that are used to create, edit, and view records in each Collection thereby changes the types of information or data to all records within that Collection. You are not constrained by how you define a Collection when you create it. For example, if you want to allow Collection stakeholders to attach a file that becomes associated with a record, add a File Upload control in the applicable Screen(s) that represent information in that Collection; the new File Upload control becomes available in all records in that Collection.
Determine which users and/or groups have permission to view, create, edit, or delete Collections by setting Collection permissions. These permissions are different than record permissions that specify which users and/or groups can manage records within an individual Collection.
Import a CSV file into a Collection to simultaneously create multiple records from the CSV file's data records.
Establish relationships between records in one Collection with those in a second. A Collection relationship links two Collections by designating one Collection as a parent Collection, the other as a child Collection, and defining data keys or columns linking both Collections. The Collection from which this relationship is created is automatically designated as the parent Collection. The relationship is a one-to-many relationship such that a record in the parent Collection can have multiple matching records in the child Collection.