Manage organization-wide settings by navigating the side menu to Organization & Users > Organization Setup.
The Organization Setup page allows you to view and control company details such as name & logo and regional date, time & measurement settings, and more advanced settings such as metadata, email addresses, and API access.
Edit Organization
Basic Settings
| Setting | Description |
|---|---|
| Name | Enter the name of your company. |
| Description | Enter a brief description of your company. |
| Logo Image | Upload your company’s logo, which will be displayed in the app/on devices. |
| Letterhead | Upload your company’s letterhead, which can be used when printing or exporting form uploads. |
Regional Settings
| Setting | Description |
|---|---|
| Country | Country in which your organization is located. |
| Default Time Zone | Enter the format in which 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 |
| Date Format | The default time zone controls the time you see date and time entries. It automatically considers daylight saving time when active if you select a region that uses it. |
| Time Format | Enter the format in which 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 |
| Measurement System | 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. |
| Start of Calendar Week | Choose how calendars across the platform should display the start of the week. |
Email Options
| Setting | Description |
|---|---|
| Default Sender Email / Name | The default sender’s name and email address will be used on automated emails the system sends. If you prefer, you can leave this field blank NOTE: The recipient email servers may reject emails if you do not have an SPF record set up for the sender’s web domain. |
| Send Invite Emails To | All User Invite or Reactivation emails will be sent to the email address defined. The email will be forwarded to the invited user if this field is left blank. |
| Reroute Password Resets | 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 to prevent this behavior, and instead, send Forgot Password emails using the ‘Send Invite Emails’ name and email address. |
| Send Notifications To | When errors and other important events occur, emails will automatically be sent to the given comma or semicolon-separated addresses. These events can also be seen in the Notifications area 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. |
Advanced Options
Integrations
API Keys
| Setting | Description |
|---|---|
| Company ID | 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. |
| Private Token | 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 o}xox%PRIVATETOKEN}} builtin for use in REST connectors. |
| API Full Access Keys | Data marked as personal/sensitive will be returned as plain text in responses. Maintain your integration by using one key when regenerating the other. |
| API Anonymize Keys | 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. |
| Enable User API Keys | 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. |
Global Service Endpoints
| Setting | Description |
|---|---|
| Form REST Connectors | Specify a global REST endpoint for use by REST Form connectors. |
| Task REST Connectors | Specify a global REST endpoint for use by REST Task connectors |
| Data Source Sync | Specify a web service endpoint that can be used globally in Connectors, such as Platform Sync. |
| Mapping Tiles for App | System-provided map tiles are used by default on the app to display maps to users. If you wish to use your custom map tiles (e.g., from a GIS system), specify a URL template here. The URL must contain {z}, {x}, and {y} placeholders, representing the zoom level, X, and Y decimal coordinates to be passed to your tile source provider. Some examples: https://tile.openstreetmap.org/{z}/{x}/{y}.png https://[host]/arcgis/rest/serv/map/tile/{z}/{y}/{x} |
Email Service
Use SendGrid Email Service to manage the sending of system emails – e.g., a web service.
Additional information:
- Configure Email Support for Your Custom Domain (SPF & DKIM)
- Use Your Own SendGrid Account
External User Authentication and Provisioning
Authenticate your users against an external system for single sign-on, such as a web service or enterprise identity provider. User passwords are never stored on our platform when external authentication is configured.
Connectors:
Security
General
| Setting | Description |
|---|---|
| Session Expiry | The password policy is 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 that favours complex passwords that are hard to break (but also harder to remember!). |
| App Session Expiry Time | Specifies the maximum amount of time that a user session is permitted to remain logged into the app without any activity. Upon expiry of this timespan, the user will be automatically logged out. |
| Password Policy | Select the length of time user passwords will be valid. Users will need to set a new password when it expires. i.e., 14 days, 30 days, 90 days, 180 days, 1 year, Never. |
| Password Length | If required, define a larger minimum password length than the one in your selected Password Policy |
| Password Expiry | Select the length of time user passwords will be valid. Users will need to set a new password when it expires. i.e. 14 days, 30 days, 90 days, 180 days, 1 year, Never. |
Two-Factor User Authentication
| Setting | Description |
|---|---|
| Enable/Disable 2FA | Enable two-factor authentication for your organization so that users have an additional level of identity verification required for logging in. This is an added security for your organizational data. Options: Disabled (default) Enable for Portal Only Enable for Portal & App |
| Verify User On | Specify when the user should be challenged to verify their identity via two-factor authentication (2FA). By default, we require a verification code when the user first registers for 2FA and once per app install thereafter. For additional security, you can require every login be verified – for Portal users specifically or for all users. NOTE: If you choose to require verification on every app login, your users will always require an internet connection in order to verify their 2FA code. |
| Authenticator | Specify your preferred authenticator app, which will be recommended to your users during their 2FA registration process. |
IP Whitelisting
| Setting | Description |
|---|---|
| Add Rule | Optionally create rules that apply access restrictions to the specified areas based on the IP address of the requesting user or program.If no rules are defined for the given area, then all IP addresses are permitted. Users with the Enterprise Admin access level are exempt from portal restriction rules to ensure access continuity. |
Secure Score
Ensure your account is as secure as possible by configuring and setting applicable high-risk areas.
Customize Messages
Message Settings
| Setting | Description |
|---|---|
| Default Sender Name | The default “From” name is used on any automated emails the system sends. |
| Default Sender Email | The default “From” email address is used on any automated emails the system sends. NOTE: Recipient email servers may reject emails if you do not set up an SPF record for the sender’s web domain. Learn more about SPF here. |
Email Subjects & Bodies
Customize email subjects and bodies in HTML for system-generated emails with placeholders. The table below shows what are the mandatory or optional placeholders you need to include in your custom email.
| Email Type | Placeholders |
|---|---|
| User Invite Email | Required Placeholders: {PASSWORD}, #IFWEBACCESS, #ENDIFWEBACCESS – these MUST remain in the body. Optional Placeholders: {COMPANY}, {EMAIL} |
| User Forgot Password Email | Required Placeholders: {RESETREQUESTID} – these MUST remain in the body. Optional Placeholders: {COMPANY}, {EMAIL}, {PASSWORD}, #IFWEBACCESS, #ENDIFWEBACCESS |
| File Email | Optional Placeholders: {0} (User’s name), {1} (Type of Object – e.g. Form) |
| Notifications Alert Email | Required Placeholders: {NOTIFICATION_TABLE} – these MUST remain in the body. Optional Placeholders: {COMPANY} |
Connections
Add Connections to authentication communication between external systems for Form and Data Source Connectors to push or pull data.
i.e., Amazon Web Services, Google, OneDrive, SQL Server, and more.