App should present users with a form to create or edit records. Internally each app record is a page, therefore developers can include/exclude/replace Page properties and add new properties to fit their apps.

Here are the default properties that come with every record

• ID: id of the record
• Type: the main type of the record i.e: Page, Collection, Product or App.
• Subtype: the secondary type of the record i.e: Ticket, Blog.
• Creator: the person first creates the record.
• Created: the date the record was created.
• Updated: the date the record was updated.

Here are the built-in properties and settings that app may include or exclude for its record

• Tab Content: the Content tab will not be shown if excluded
• Separate Tab for App: if enabled, app's new properties will be shown in a separate tab instead of being appended to the Content tab
• Label: display name of the record
• Slug: URI of the record, required for accessing the record via the website
• Page Title: the HTML title of the record
• Meta Description: the HTML meta description
• Content: the content of the record
• Visual Editor: include or exclude Visual Editor for the content
• Featured Image: the main image for the record
• Multilingual Support: enable/disable multilingual for app

• Tab Settings: the Settings tab will not be shown if excluded
• Page Layout: custom layout for rendering the record on the website
• Add to Menu: add the record as a menu item in the specified menu
• Collection/Category: add the record to specified collections/categories
• Breadcrumbs: show navigation path when rendering the record on the website
• Private: make the record private and available to registered users (with specified permission) only
• Published: publish the record to website
• Start Date/End Date: specified the date the record will be published
• Status: the current status of the record

If a built-in property is not formatted as desired, just exclude it and create a new input field for that property in desired format.

App developers may add new input fields to capture more data for the records. There are many pre-defined fields such as:

• Text/Textarea: text input field
  
  
• Lookup: a lookup field that returns the IDs of matching object name (e.g: a Page name, a Product name, a User name).
  
  Supported objects are: creator (user), staff, group (role), page, collection, menu_id, product, variant, sku, app name (e.g: feature_request).
  
  A scope can be specified as the default value to limit the lookup scope to objects having the specified status, the format is: 
  
  - Scope::Status_Name e.g: Scope::Active
  - For collection, this value will limit the lookup scope to the collection subtype e.g: Scope::Product or Scope::App::Blog.
  - If the scope is set to Scope::SubRecords, Lookup will look for objects which are sub-records of given parent ID, e.g: enter an ID for a state to retrieve all cities in that state.
  
  Lookup fields should be used for staff side only as what can be looked up is restricted by the current user's permissions. Client cannot lookup but can view the looked up values if they are published or created by themselves. Lookup field is read-only in the customer portal, customers won't be able to lookup but can view existing lookup result.
  
  
• Select/Radio: a field that consists several options to choose.
  
  Options can be pre-defined or retrieved from Per Site Settings by using From::configs as the first option (field name should be the same as the Settings' field name) or can be looked up by specifying From::lookup as the 1st option, object (creator, page, permission) as the 2nd option and optionally a value to lookup as the 3rd option.
  
  The value to lookup can be set to:
  
  - Scope::Status_Name/Scope::SubRecords like the lookup field above, 
  - {{poster}} to retrieve the current user.
  - It can also be set to another field's value by specifying From::input as the value and the other field's name as the 4th option. Scope::SubRecords can also be set as the 5th option to change the scope. One example for this feature is creating a City field to lookup using the value chosen for the State/Province field, when a State/Province is selected on a form, the City field will be updated with all cities in that particular State/Province for users to choose. 
  
  
• File/Image: a file/image field that allows uploading of file/image or selecting a file/image from File Manager
  
  
• Checkbox: a checkbox field
  
  
• Radio Hover: a radio field that shows the selected or default option and upon mouse hovering, shows other available options to choose (e.g: an emoji selection)
  
  
• Rating: a clickable/slidable field that consists 5 stars to allow choosing a rate out of 5. Half-star or a rate of 4.5 is also supported.
  
  
• Percentage: show how many percentage has been completed, the value should be in percentage i.e: 80% or 80.
  
  
• Date/Time: an input box to select date/time
  
  
• Currency: an text field that is displayed using site's currency format
  
  
• Duration: a read-only field to convert second to hour/minute. The value for this field can be set by automated actions.
  
  
• Password: a password field that can be used to store sensitive credentials, the value will be encrypted
  
  
• URL/Email/Tel/Color: standard input fields
  
  
• Country: a dropdown field for selecting a country 

To create a custom field, just choose a field type, name (id), label (display name) and description (optional) for it. You can also set field visibility, a default value, whether the field is required or optional or accepting multiple values (select and lookup field only), and specify options if the field supports them. The default value can be set to From::configs to retrieve the configured value for the same field name in the App configuration (set by Site Manager). When listing app records, by default, only the ID and Name/Label of the record are returned. If a field should be included in the return, it needs to be marked as a Listing Column.

When a field's visibility is set to Client Hidden, Hidden or ReadOnly, it is not visible (except ReadOnly) or savable by respective user groups but can be changed by Automated Actions. While Client/Staff ReadOnly prevents respective user groups from changing existing values, it does allow them to set a value at the time the record is created. On the client side, ReadOnly field is only displayed when it has a value or it is a required field.

There are two ways to create a hidden property. One is to create a custom field with hidden visibility and a default value. The other way is to use Automated Action to change the property to a desired value when a record is created/updated or both (posted). App also has several hidden properties that are not saved but can be used to manipulate other properties, such as:

• collection_replace (array, string): can be used to remove the record from all existing collections and add it to collection(s) specified by collection_replace (valid collection IDs only in an array or comma separated string).
• _public: can only be set by Automated Actions to add data to the record's public property. This property allows anyone to update it via Automated Action and is suitable to store aggregate data for the record such as rating, likes, average star etc.
• $: used to store temporary value while app's automated actions are evaluated.
• @user (array, string): used to set page level permission to allow read access from specified User IDs. This will override page level permission set by app (if any).
• @user_write (array, string): used to set page level permission to allow read/write access from specified User IDs
• @staff (array, string): used to set page level permission to allow read access from specified Staff IDs
• @staff_write (array, string): used to set page level permission to allow read/write access from specified Staff IDs

Action Button can be used to set a value for a field/property and save the current record immediately with just a single click, for example you can set different statuses for a record using different buttons. The button's value will override or set the corresponding property's value if the property is editable or missing, it will be ignored in case the property is hidden or readonly (will not work with automation). Action Buttons can be used with the Automated Action to trigger other actions (update other apps, send notification or webhook etc).