Knowledgebase

Enter the format you would like dates to be displayed.

Valid options are:

d, dd = day

ddd, dddd = day of week

M = month

y = year

Examples: MM/dd/yyyy, dd-MMM-yyyy

Enter the format you would like times to be displayed.

Valid options are:

h = hour

m = minute

s = second

tt = A.M. or P.M.

h/H = 12/24 hour

hh, mm, ss = display leading zero

h, m, s = do not display leading zero

Examples: HH:mm, hh:mm tt, HH:mm:ss

Controls whether measurement values are displayed to users with metric or imperial system units (e.g. meters vs feet).

After changing, please check anything that relies on measurements to ensure their values are correct e.g. "Must Complete Within" on tasks and Location fields on screens.

Repeated data (e.g. repeatable pages in a Form entry) is exported by the platform as separate rows for CSV and other tabular formats.

When this option is selected, all non-repeat answer values are copied down into each repeat row.

This can be useful for cases where other systems are importing these tabular exports, and those systems need to process all answer values on every repeated row.

If you wish to instead have blank cells for non-repeat answers in repeat rows, unselect this option.

Turning off this option effectively provides a grouping mechanism within the tabular export, with only repeat answer values populated in repeat rows. This can be useful for cases where the exported tabular file is being reviewed by humans instead of machine imported.

Example:

If selected, every Task will automatically be marked as complete when the assigned user checks off all activities on the Task.

If this option is not selected, assigned users will need to manually confirm completion of each Task. This can be useful when you wish to allow the user a chance to add notes on Tasks prior to marking as complete.

Enable this option to ensure that data exports apply the time zone of the submitting app user instead of the organization time zone.

Be sure to specify a time zone for each of your App users via the Edit User page.

• https://secure.appenate.com/
• https://secure-eu.appenate.com/
• https://secure-au.appenate.com/

Useful for external integrations, where a shared private token is needed for authentication. This is system generated by default, but you can specify a value from an external system/integration if you prefer.

Automatically included in Hosted GET calls for this reason. Accessible via the {{%PRIVATETOKEN}} builtin for use in REST connectors.

Data marked as personal/sensitive will be returned as plain text in responses.

Maintain your integration by using one key when regenerating the other.

Data marked as personal/sensitive will be converted to a non-human-readable format in API responses.

Maintain your integration by using one key when regenerating the other.

By default, API access is available using organization level API keys, however, these keys give full access to all API endpoints without restriction.

When integrations are being built by internal developers this is generally not an issue, however, if you need to provide external/third-party integrators with API access then more granular control will be needed.

You can enable granular control via this option, which activates the ability to generate API access keys on a per user basis. When our API is accessed via a user API key, our system automatically applies the access level and permissions of that specific user to their requested API operation.

For example, if the given user has an access level of Read-Only, then API calls using their access key will only be permitted to perform GET operations on our API endpoints. Similarly, if the user does not have permission to access Data Sources, then all attempts to access our Data Source API with their key will be refused.

In this way, you can set up a dedicated, access restricted user for your external developer and easily control which API calls they are able to make.

Specify a web service endpoint that can be used globally by Platform Sync and connectors in Data Sources.

Find Out More

• REST
• Okta
• Azure Active Directory
• Ping Identity

The password policy enforced for all users on the platform when they set/change their password. All passwords are also checked against a list of common passwords that are not allowed.

Basic

A simple 6 character minimum password policy.

NIST SP 800-63

A phrase-based policy that is human-friendly yet still hard to crack.

OWASP 2017

A strict policy which favours complex passwords that are hard to break (but also harder to remember!).

• Disabled (default)
• Enable for Portal Only
• Enable for Portal & App

If no rules are defined for the given area, then all IP addresses are permitted.

NOTE: Users with Enterprise Admin access level are exempted from Portal restriction rules to ensure continuity of access.

The default sender’s name and email address will be used on any automated emails sent by the system. This field can be left blank if preferred.

NOTE: Emails may be rejected by the recipient email servers if you do not have an SPF record set up for the sender's web domain.

Find Out More

All User Invite or Reactivation emails will be sent to the email address defined. If this field is left blank the email will be forwarded to the invited user.

By default, the system will send Forgot Password emails to the user’s email address enabling them to self-reset their password.

Check this box if you wish to prevent this behaviour from happening and instead send Forgot Password emails to the ‘Send Invite Emails’ name and email address.

Emails will automatically be sent to the given comma or semicolon separated addresses when errors and other important events occur. These events can also be seen in the Notifications area found on the web portal. 

If no email address is defined then notifications will not be sent via email but they can still be viewed in the Notifications area.