Fields that store free-text values

Custom fields will have different configurations based on the type of data stored. This section will focus on four types of custom fields:

  • Fields that store free-text values
  • Fields that store a single value from a prompt list
  • Fields that store multiple values from a prompt list
  • Fields that store a yes/no value

  Best Practices

Before configuring custom fields in Slate, carefully consider the data being captured and how it will be leveraged in Slate.

Important!

The following settings should never be changed after a field is in use:

  • Scope
  • ID
  • Prompt
  • Value

Changes to any of these may result in inconsistent and inaccurate data. If assistance is needed updating a field, submit a Service Desk request and a Technolutions team member can walk through the updating or migration process.

How to Create Free-Text Value Fields

Fields that store free-text values are generally used to collect non-standard data. If a prompt list would not effectively capture data for a particular field, then a free-text field is appropriate. Examples of this often include Explanation, Description, or Other Item fields.

To create a field that stores free-text values, enter the following User configurations:

  • Status - Set the status to Active.
  • Dataset - Leave this setting blank for now.
  • Scope - Set the scope to person. Scope describes the entity to which the field is related.
    Note: The scope should not be changed once data exists for the field. Instead, a new field with the correct scope should be created. Data can then be re-imported to this new field, and the original field can be inactivated.
  • ID - This is the code that Slate will use to store fields in the database. It is best practice to have this ID be all lowercase with no spaces or special characters other than an underscore. Once this ID is set and in use, the ID should not be changed. This ID is simply used in the storage of the data in the database, and it is not a value that most administrative staff will see.
  • Name - Give the field a name. This name will be visible administratively only. Although it is acceptable to change the name, even if data already exists for the field, be aware that changing the name of a field will also change the name of the associated exports and filters.  This would likely cause issues with queries and reports that refer to this field name.
    Note: Field names should not be duplicated, even though Slate will not prohibit it. For example, if two fields are named "Entry Term," it would be difficult to ascertain which one was person-scoped and which was application-scoped.
  • Prompt - Free-text custom fields do not use a prompt list. Leave this set to Other.
  • Value - If the field will store free-text data, if it is a related dataset field, or if it is using one of the following prompt lists: bit; language; state; or country, then configure this setting to Store Value (bit/language/state/country/user prompts and text fields only).
  • Multiple - If a record should only have one value associated with it, set this to Single Value.
  • Unique for Merging - Leave this configuration set to "Do not use value for merging". 
  • Data Type - For text-based fields, specify if the field will contain free-text, or if the field will contain certain typed values. Filters will become available in the Slate Template Library for text-based fields based on the Data Type selected. Numeric types (Real, Int), as well as Date and Date/Time types will be available as filters with comparison operators (<, <=, =, >=, >).
  • Unsafe - Leave this set to Safe. 
Was this article helpful?
5 out of 6 found this helpful