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 false true 121 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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 false true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content 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"] ) finding a field id you are able to find a field id by logging in to the system and navigating to settings > forms > editing a form > and then clicking a field the field id will be in the top of the edit window