Fields
Fields Overview
In Regpack, fields can be thought of as database entries for each user, and the different field types allow for different types of inputs. As a user completes or updates the fields on their forms, the values within this database are updated.
Among the usual fields which appear on your forms, there are a few special cases that should be highlighted first:
Special User Fields
The fields below receive special treatment within the system and are mapped to these field IDs by default (see "Mapping Fields" below for more on mapping). These fields should not be deleted.
Name | Appears in user forms | Description |
first_name | yes | This is responsible for the presentation of the first name within the Users tab and appears within a user's forms. |
last_name | yes | This is responsible for the presentation of the first name within the Users tab and appears within a user's forms. |
org_name | yes | This is an optional field available only in family/group structures that functions similarly to first_name. This can be displayed within the Users tab for the parent user upon request. |
main_email | yes | This is similar to first_name but also becomes the default username if the username option is not toggled ON in the login widget for your project. Note that emails are both validated and checked against a DNS database; however, the DNS check can be disabled in the project settings of your project. |
username | no | It is generally advised that this be the same value as main_email; however, you can provide a username other than main_email if desired. If you would like to use a username that is not an email address, you will need to make sure you have toggled this option ON in the login widget for that project. If users use the Google single sign-on functionality, username defaults to their google email. |
password | no | Passwords can be alphanumeric or special characters with a minimum length of 6. Passwords are not saved as is; they go through encryption (abstraction process before going into the database). |
System Fields
There are various fields such as widgets that have special functionality and cannot be accessed directly. System fields start with an underscore (i.e. _submit for the submit button in a form).
Instead of accessing these directly, we provide special parameters which allow you to interact with the different aspects of the system that these fields are related to. For instance, in a get_info call at the user's endpoint, you would retrieve the products in a user's cart with "_usercart":"true" rather than by trying to find the field id for a cart within your project.
Check the section for the call you are working with to see the list of available system fields.
Field types
Name | Response Type | Validation options |
Short Answer | string |
|
Long Answer | string |
|
Phone | string | Both formats allow only numeric or "+"
|
string | The default functionality is to check the structure and verify email against the DNS database | |
Date | string |
|
Country | string | No validation options but allows you to present only major countries or a complete list. Allows you to select a default country. |
Number | numeric | Allows you to limit the number range and present as either a drop down or a free input (inter or float) |
Single Checkbox | array | none |
Yes/No | array | none |
Multiple Choice | array | If set to checkbox, this field will allow for multiple answers. You have the option to send an array of strings for these fields when creating or updating users. If only a single answer is required, then you are able to submit this as either a string or an array with a single value. In responses for checkbox fields: If there are multiple answers, an array is returned. If there is a single answer, a string is returned. The return will be a string stripped of all HTML. |
E-Signature | object | Returns timestamp, IP address, and user agent data. No validation options; however, it cannot be signed by an admin (only the user may sign it). Additionally, the form locks for the user after signing. |
File Upload Widget | array | Returns the hosted link of the file as well as other items such as file name, file size, and extension type. |
Making a field admin only
Fields can be made viewable only by admins by editing the form, clicking on the field, and setting it to admin-only. This can be a useful way to have your admins answer questions about a user.
Mapping fields
The ability to map fields is only available to dev admins.
Each field in Regpack that is accessible via the API has a field ID that you can access by clicking on the field within the form editing module. By default, these will have a format such as f_41526_37415, but you are able to map them to any field ID which does/is not: (a) begin with an underscore (i.e. _no_dice) (b) already taken by a handful of Regpack mappings (we encourage you to avoid the special user field mappings). Once you have mapped a field, you may access that field within the API by using the new field name.
For instance, the question "What is your favorite color?" might be mapped as favorite_color.
It's important to note that mapping fields certainly comes with some risk, specifically if you have identical mappings within the same project. Users will overwrite answers with the same mapping which can lead to confusion.
This said, mapping fields is a powerful way for you to build an information network within your organization as it allows you to centralize core fields between various projects and have user data from various sources flow into this central project.
Referencing fields in API calls
Fields are supplied to the API calls via doc. Either the native field IDs or the mapping you provide serves as the keys. When referencing fields in get_info, the values are boolean (as in favorite_color:true), while any other calls are expecting either a string/numeric (as in favorite_color:"pink" or favorite_number:2) For multiple-choice fields, values present as an array of strings (as in favorite_colors:["pink", "purple"]).
