Overview

This article provides guidance on how to configure your system, authentication, and integration settings and monitor system activity in the Appian Administration Console. The administration console is where system administrators can update certain configuration properties through the web interface. Users must be system administrators to make changes in the Administration Console.

Accessing the administration console

To access the Administration Console, in your Appian environment, go to > Admin Console.

Only users of type System Administrator can access the Administration Console and make changes to the configurations. The Administrator user is specifically prohibited from accessing the Administration Console in order to ensure that all changes can be traced to a specific named user rather than a shared account.

All changes made through the Administration Console are logged to an audit log. The log captures the username of the user that made the change along with the previous and new values of the changed property.

See also: Appian Administration Console Logging

System

The following pages relate to system administration.

Branding

The Branding page allows you to manage the name, logos, and colors that appear throughout the Tempo interface. The branding settings only apply to the web interface. For branding of the mobile interfaces see the Custom Mobile Applications documentation.

All branding modifications result in an audit log message with the username of the user who made the change, the previous values, and the new values.

Note that the Branding configurations only apply to Tempo. To learn about custom styling for embedded interfaces, see Themes.

Identity

• Site name - The site name appears as the browser window title and in emails sent from the system.
• Logo - The logo appears on the login page and on the left side of the end-user interfaces. The Appian logo in the upper-right corner of the end-user interface cannot be branded. The logo is automatically resized for use in each interface. The logo file should be a PNG file with a transparent background and must be less than 100KB. As an alternative to uploading an image, the logo can be configured to point to a static image hosted on a separate web server. Use this option when your company web assets, such as logos, are hosted on a content delivery network. The default logo is the Appian logo.
• Logo Alternative Text - The alternative text provided in this configuration is used for the logo's alt attribute and announced by screen readers in Tempo. The value should describe the logo to visually impaired users, including any text that is part the logo. It does not apply to the email logo. Default is: Logo.
• Email Logo - The logo appears at the top of system-generated emails to users, such as those sent when a task is assigned or when a user is added as a participant to a post. The same recommendations mentioned above for the logo apply to the email logo.
• Favicon - The favicon (short for "favorite icon") is the small icon that appears in the browser tab or URL bar. Provide an ICO file with sizes 16x16 and 32x32. Like the logo, the favicon file must be less than 100KB. The favicon can also be configured to point to an externally-hosted favicon file. Use this option when using a content delivery network. The default favicon is the Appian "A" icon.
• Display Site-Wide Banner - This option determines whether or not to show a banner at the top of all pages in the Appian environment. Currently, this banner only shows up in web.
  • Banner Message (Required) - The text to display in the site-wide banner. This field is only visible after selecting Display Site-Wide Banner.

Colors

• Navigation Bar - The color of the navigation bar in the end-user environment. The default value is #416b88.
• Navigation Labels - The color of the navigation labels in the navigation bar (News, Tasks, Records, etc.). The default value is #ffffff.
• Navigation Highlight - The color of the navigation labels when a user hovers over the label with the cursor. Also, the color of the underline that indicates which navigation label is currently selected.The default value is #f8e85b.
• Filter Group Title - The color of the title that appears above the filter groups in the left navigation pane (e.g., "Status" on the Tasks tab). The default value is #222222.
• Accent Color - Affects the color of many elements in all interfaces, including buttons, links, active field border colors, milestone bars, section titles, etc. Avoid grayscale colors (black, white, and gray) that are similar to colors used for interface elements and avoid green/red colors that are used to indicate positive/negative values. The default value is #1d659c.
• Loading Bar - The color of the bar at the top of the page that indicates when the system is processing. The default value is the accent color.
• Wallpaper - The color of the background that surrounds the main content area. The default value is #ebf1f7.
• Email Header Color - The color of the top part of system-generated emails to users. The default value is #1d659c.
• Email Accent Color - The color of the navigation button in system-generated emails to users. The default value is #1d659c.
• Banner - The background color for the site-wide banner. The default value is #666666.
• Banner Text - The color of the text for the site-wide banner. The default value is #ffffff.

Data retention

The Data Retention page allows you to manage the following settings:

• Allow News Entry Deletion - Allow users to delete news entries and social tasks that they have authored, as long as nobody has commented. The default is that news entry deletion is allowed.

• Enable Periodic Cleanup of Deployment Packages - Allow deployment packages (zip files) to be automatically deleted after the specified number of days. The default is 30 days. Appian recommends setting 30 days or less for package cleanup to ensure optimum disk space.

  • Deployments with deleted packages will still appear in the deployments view's history. However, these deployments will be archived and have limited functionality.

File upload

The File Upload page allows customers to manage the following settings:

• Enable Real-Time Virus Scanning (Cloud Only) - When enabled, all files under 25MB that are uploaded in the following places will be scanned immediately upon upload: Tempo News, Social Tasks, interfaces in all locations (Tempo, Sites, and Embedded interfaces), the Administration Console, and the Appian Designer. Nightly scans will continue even if real-time scanning is disabled. Files found to contain viruses are logged in the blocked files audit log.
• Block files with the specified extensions - If chosen, Appian will block any file with an extension listed in the Extensions to Block field. Choosing this option allows you to disable the feature by leaving the Extensions to Block input blank.
  • Extensions to Block - A case-insensitive list of extensions to block separated by whitespace (spaces, tabs, or new lines). The values provided are matched exactly as written, case excluded. For example, specifying "jpg" will not block "jpeg" files.
  • Block files without an extension, e.g., "my_file." and "my_file" - When enabled, files without an extension will be blocked. If file type verification is enabled, this field will be checked and disabled because files without an extension do not have a valid type.
• Only allow files with the specified extensions - If chosen, Appian will block any file with an extension not listed in the Extensions to Allow field.
  • Extensions to Allow - A case-insensitive list of extensions to exclusively allow separated by whitespace (spaces, tabs, or new lines). The values provided are matched exactly as written, case excluded. For example, specifying "jpg" will not allow "jpeg" files.
  • Allow files without an extension, e.g., "my_file." and "my_file" - When enabled, files without an extension will be allowed. If file type verification is enabled, this field will be unchecked and disabled because files without an extension do not have a valid type.
• Block any file with an extension that does not match the underlying file type - When enabled, Appian will analyze the file contents of uploaded files to determine the type of the file. If Appian successfully identifies the file type and the type does not match the extension, the file will be blocked regardless of the configured extension list. If the underlying file type or the file type associated with the extension cannot be determined, the extension will be trusted and checked against the extension list above.

Using file type verification effectively

File type verification can be toggled on and off through the checkbox labeled "Block any file with an extension that does not match the underlying file type". To fully leverage this powerful feature, we recommend enabling it in coordination with a list of extensions to allow rather than a list of extensions to block. We recommend this for two reasons:

1. It is more secure. It is very difficult to enumerate all possible extensions that could be dangerous to your users.
2. They work well together. If Appian finds an extension or file type that it does not recognize, it assumes that the file has a valid extension. The purpose of this feature is to allow proprietary file extensions that may not be in our database through. It does mean, however, that users can rename files to a nonsense file extension, like "asdf", to bypass the list of blocked extensions and file type verification. A list of exclusively permitted file extensions avoids this issue.

Internationalization

The Internationalization page allows you to set the primary language and time zone displayed to users. This page also controls the calendar types and languages that are enabled for the site.

Language settings

The table below lists the default languages available for selection. Text is only translated in the interfaces listed below, as supported. When a new version of Appian adds support for a new language, the translated interfaces may only include support for the Tempo and Mobile interfaces.

Language	Language Code	Interface Support
		Tempo/Mobile	Administration Console	Appian Designer	Portal
Arabic	[ar]	Yes/No	Yes	Yes	No
Chinese (Simplified)	[zh_CN]	Yes	Yes	Yes	Yes
Chinese (Traditional)	[zh_HK]	Yes	Yes	Yes	Yes
Dutch (Netherlands)	[nl]	Yes	Yes	Yes	Yes
English (United Kingdom)	[en_GB]	Yes	Yes	Yes	Yes
English (United States)	[en_US]	Yes	Yes	Yes	Yes
French (Canada)	[fr_CA]	Yes	Yes	Yes	Yes
French (France)	[fr_FR]	Yes	Yes	Yes	Yes
German (Germany)	[de]	Yes	Yes	Yes	Yes
Greek (Greece)	[el]	Yes	Yes	Yes	Yes
Hebrew	[iw]	Yes/No	Yes	Yes	No
Italian (Italy)	[it]	Yes	Yes	Yes	Yes
Japanese (Japan)	[ja]	Yes	Yes	Yes	Yes
Korean (South Korea)	[ko]	Yes	Yes	Yes	Yes
Polish (Poland)	[pl]	Yes	Yes	Yes	Yes
Portugese (Brazil)	[pt]	Yes	Yes	Yes	Yes
Russian (Russia)	[ru]	Yes	Yes	Yes	Yes
Spanish (Mexico)	[es]	Yes	Yes	Yes	Yes
Swedish (Sweden)	[sv]	Yes	Yes	Yes	Yes

Enabling languages

Enabling a language makes it available for users to select as their language setting. To enable a language, select it from the Enabled Languages dropdown and click Save. When enabling language settings, consider:

• Appian must have at least have one language enabled. If no languages are selected, you must enable at least one language before you can save your changes.

• For Appian Mobile applications, start and task forms appear in the language and locale preference set in Appian, News feed entries appear in the language they were entered, and the remaining aspects of the mobile application, such as button names and titles, are determined by the device's language setting. The device's language setting does not need to be enabled as a language in Appian to translate the button names correctly.

• The process modeler is translated to the developer's preferred language, except for the following areas: the node and smart service palette, the font palette, and some validation messages.

• When language is set to Arabic, the interface displays from right-to-left rather than left-to-right and default alignment for interface components and grid columns is right rather than left.

Disabling languages

A language can be disabled by clearing the check from the dropdown that corresponds to the language. When a language is disabled, the primary language for the site is displayed for users whose preferred language setting is set to the disabled language. Users then can select a new preferred language from one of the remaining languages that are enabled for the site.

Selecting a primary language

To specify a primary language for your site, select a language from the Primary Language dropdown. The primary language is used for users who have not selected their own preferred language. Note that only enabled languages are listed here.

Setting a system-wide language

To use the primary language for all users regardless of their preferred language, select the Always override users' selected language checkbox.

NOTE: Selecting the Always override users' selected language checkbox ensures that user preferences are never enforced. Irrespective of user preferences, the primary setting is then always applied.

Date and time settings

The preferred language setting governs the format of dates and numbers that are displayed by the system. For example, if the preferred language is set to English - United States, the date is displayed with the month preceding the day. The same date, when the preferred language is set to Spanish, is displayed with the day preceding the month.

Display formats used by default locales

The following table lists the date and time formats used when a certain default locale is selected as the preferred language (or as the only enabled language).

Preferred Language	Date and Time Format	Example
US English (en_US)	Month Day, Year Hour:Minute AM/PM	Dec 15, 2010 3:32 PM
UK English (en_GB)	Day Month Year Hour:Minute	15 Dec 2010 15:32
French (ca_FR)	Year-Month-Day Hour:Minute	2010-12-15 15:32
Spanish (es_MX)	Day/Month/Year Hour:Minute	15/12/2010 15:32

Hours displayed in US English use a 12-hour clock with an AM or PM designation.

Number formats

The separators between digits in a number change based on the preferred language. For example, if the preferred language is English - United States, a comma (,) is used as a separator (1,000). If however, the preferred language is set to German - Germany, a full stop (.) is used as the separator (1.000).

Calendar settings

According to the US Naval Observatory, the Gregorian calendar is the internationally accepted civil calendar. This is the default calendar used in Appian.

Selecting a primary calendar

To change the default Gregorian calendar to a different calendar type, select a calendar from the Primary Calendar dropdown. Options include the calendar types listed below.

Islamic calendar types

You can select from three types of Islamic calendars, which use slightly different leap year patterns and different means for calculation.

Type	Leap Years	Description
1	2 5 7 10 13 16 18 21 24 26 29	Kūshyār ibn Labbān (11th cent. CE) Ulugh Beg (15th cent. CE) Similar to the "Kuwaiti algorithm"
2	2 5 7 10 13 15 18 21 24 26 29	Most Commonly Used
Um Al Qura Calendar تقويم أم القرى	Not applicable	Based on observation or astronomical calculation.

The leap year patterns are based on the following logic:

• There are 11 leap years in a 30 year cycle. Noting that the average year has 354 11/30 days and a common year has 354 days, at the end of the first year, the remainder is 11/30ths of a day.

The difference between calendar type 1 and type 2 centers on when the leap day is added.

• With calendar type 1, whenever the remainder is at least half a day (15/30ths of a day) a leap day is added to that year, reducing the remainder by one day.
• With calendar type 2, when the remainder exceeds 15/30ths of a day, a leap day is added.

The difference between the Type 1 and Type 2 leap-year schemes are shown in the following table, which lists the remainder for each year in the 30 year cycle.

Year	Type 1 remainder	Type 2 remainder	Year	Type 1 remainder	Type 2 remainder	Year	Type 1 remainder	Type 2 remainder
1	11/30	11/30	11	1/30	1/30	21	7/10 *	7/10 *
2	22/30 *	22/30 *	12	2/5	2/5	22	1/15	1/15
3	1/10	1/10	13	23/30 *	23/30 *	23	13/30	13/30
4	7/15	7/15	14	2/15	2/15	24	4/5 *	4/5 *
5	5/6 *	5/6 *	15	1/2 *	1/2	25	1/6	1/6
6	1/5	1/5	16	-2/15	13/15 *	26	8/15 *	8/15 *
7	17/30 *	17/30 *	17	7/30	7/30	27	-1/10	-1/10
8	-1/15	-1/15	18	3/5 *	3/5 *	28	4/15	4/15
9	3/10	3/10	19	-1/30	-1/30	29	19/30 *	19/30 *
10	2/3 *	2/3 *	20	1/3	1/3	30	0	0

Islamic calendar epoch

The epoch defines the starting point of the Calendar (the first day of year one). The following epochs can be selected for Islamic Type 1 and 2 calendars.

Epoch	Day 1 / Year 1	Description
A	15/July/622 CE/Julian	Thursday or Astronomical Epoch
B	16/July/622 CE/Julian	Friday or Civil Epoch

Setting a system-wide calendar

To override all users' preferred calendar settings with the primary calendar type, select the Always override users' selected calendar checkbox when selecting the primary calendar type.

NOTE: Selecting the Always override users' selected calendar checkbox ensures that user preferences are never enforced. Irrespective of user preferences, the primary setting is then always applied.

Selecting a primary time zone

Language preferences and time zone preferences affect how dates and times may be displayed. For example, a process start time of Oct 12, 2011 at 5:00 pm Eastern is displayed differently for a user with Spanish language and Central time zone preferences.

Process start time	User’s Preferred Setting	User’s Preferred Time Zone	Displayed start time
Oct 12, 2011 at 5:00 PM Eastern Daylight Time	Spanish - Mexico	Ciudad de México (México) (America/Mexico_City)	12/10/2011 at 4:00 PM GMT-05:00

As with languages, system administrators must also specify a primary time zone for the site. At installation, the primary time zone is set to Greenwich Mean Time (GMT). To specify another primary time zone for the site, click the Primary Time Zone dropdown and select a time zone from the list. This recommended list is based on the selected language. System adminstrator’s can override the default list of recommended time zones or add a list for a new locale by modifying the custom.properties file.

To override all users' preferred time zone settings with the primary time zone, select the Always override users' selected time zone checkbox.

When selecting a Continental US time zone, we recommend using the following settings.

• Eastern – America/New_York
• Central – America/Chicago
• Mountain – America/Denver
• Pacific – America/Los_Angeles

A process model can take a specific time zone, which is used by each process spawned from the model. Alternatively, models can be configured to use the time zone preference of the user who starts the process model. This is set in the process model's properties.

NOTE: Selecting the Always override users' selected time zones checkbox ensures that user preferences are never enforced. Irrespective of user preferences, the primary setting is then always applied.

Mobile

The Mobile page allows you to manage settings for your organization's mobile devices:

• Enable Push Notifications - Push notifications are only available on Appian Cloud and are encrypted end-to-end. The default is that push notifications are enabled.
• Enable Offline Mobile - When offline mobile is enabled, data may be stored on mobile devices to support offline use. The default is that offline mobile is enabled. Encryption of data stored on devices relies on the mobile operating system's native encryption capabilities. Data is encrypted by default on all iOS devices. Some Android devices don't encrypt data by default. Go to the security settings on your Android device to enable encryption.
• Enable Location Capture - This feature allows designers to configure any task to capture user location when submitted from the mobile application. For location to be included with the submitted form, users are required to grant location access to the application. The default is for location capture to be enabled.

• Prompt Users to Download App - Displays a redirect page to encourage users to open links in the native mobile application (if already installed), or to install the application. The logo and the button accent color can be configured by changing the Logo and Accent Color on the Branding page.

  

  • iOS App Download Link - Download URL for the iOS application. The default URL points to the Appian Mobile iOS application on the iOS App Store.

  • Android App Download Link - Download URL for the Android application. The default URL is the Appian Mobile Android application on the Google Play Store.

    The redirect page will not be displayed from the Safari browser running on iPadOS, due to a change made by Apple that makes Safari running on an iPad indistinguishable from Safari running on a desktop.

• Require Minimum iOS App Version - Should Appian iOS apps that connect to this server be required to be at or above a certain version? The default is that there is no minimum version.
  • Minimum iOS App Version - The minimum version number for an Appian iOS app that can connect to this server.
• Require Minimum Android App Version - Should Appian Android apps that connect to this server be required to be at or above a certain version? The default is that there is no minimum version.
  • Minimum Android App Version - The minimum version number for an Appian Android app that can connect to this server.

Permissions

The Permissions page allows you to control user actions to various actions on Tempo.

User profile

The User Profile section allows you to specify what information users are allowed to update from their user profiles, and whether users will be able to see the profile details of other users.

Editable fields

The fields that are set to be not editable here are displayed but disabled to users in their user profiles. Each checkbox on the page corresponds to a set of user profile fields as follows:

• Profile Photo - Profile photo
• Cover Photo - Cover photo
• Name - First name, middle name, nickname
• Email - Email address
• Phone numbers - Office telephone, mobile telephone
• Location - City, state, country
• Supervisor - Supervisor
• Title - Title
• Blurb - Blurb

Default user profile visibility

If this option is selected (the default) users will be able to see the profile details of a user if that user's role map has no viewers configured and notification emails sent by Appian will include users' display names. If unselected, no users will see that user's details unless they are explicitly added in the viewers role of that user and notification emails sent by Appian will only include users' usernames, not their display names. Regardless of the value given for this property, if the viewers role is non-empty, only those users set in the viewers role will be able to see that user's profile details.

Quick apps

Update Quick Apps settings on the Permissions page in the Appian Administration Console. This section contains the configurations to enable Quick App creation.

Add users to the quick app creators role

This link opens the Quick App Creators group. Adding users to this role gives them access to the Quick Apps Designer.

Quick apps data source

The data source chosen in this dropdown is the location where tables will be generated and updated for new Quick Apps. No Quick Apps can be created until a value is selected here.

Changing this value will only affect new Quick Apps. Any existing Quick Apps will remain connected to the data source selected at the time they were created, even when the Quick App is updated from the Quick Apps Designer.

Error messages

The Error Messages setting allows you to control the level of technical detail that you want to include in error messages that your basic users may encounter when working with expressions, interfaces, views, or actions. System administrators, and basic users in the (system) Designer group, will always see detailed error messages when working with these objects and components. Setting options are enabled or disabled; the default setting is enabled.

Detailed error messages

Enabling this setting provides basic users with detailed error messages that may include system information and object-specific information, like object references and details about why the expression error occurred. For example, the detailed error message below includes information about the expression error, the error type ID, the affected expression rule and parameter, and the code line where the error occurred.

Simplified error messages

Disabling this setting prevents basic users from having access to unwanted technical information. Instead, they will see a simplified error message that includes an identifier and instructions to contact the application administrator as shown below.

The application administrator should provide the system administrator with the Error Message Identifier so they can use it to view further details about the error in the Design Error log.

Tempo

This section contains the configurations to control Tempo access.

Edit the tempo users group

This link opens the Tempo Users group. By default, all users can access Tempo. Removing members or membership rules from this group will prevent those users from accessing Tempo.

Plug-ins

The Plug-ins page lists all plug-ins that are available in the environment. You can add and delete plug-ins in the current environment, as well as compare plug-ins across environments. The plug-in list and comparing plug-ins across environments is also available in the Objects View in Appian Designer.

All plug-ins are use-at-your-own-risk, and their functionality is not guaranteed by Appian. All plug-ins should be tested thoroughly. For more details about individual plug-ins, visit the Appian AppMarket.

This page provides the following information about each plug-in:

• Name - The name of the plug-in.
• Version - The version number of the plug-in.
• Description - The description of the plug-in as written by the plug-in creator.
• Modules - The modules that are included in this plug-in. The name of each module is categorized by its type: Component, Connected System, Function, Function Category, Smart Service, Data Type, or Servlet.

The plug-in names, descriptions, and modules in the plug-ins list is provided by the plug-in manifest file when you deploy a plug-in.

If a user changes the access to a plug-in, then there will be an audit log message that will track the username of the user making the change, the previous value, and the new value.

By default, no plug-ins are allowed to access the Encryption Service. An administrator must explicitly grant access to each plug-in. Once granted, all modules within the plug-in may use the Encryption Service. The Encryption Service allows the plug-in to encrypt or decrypt values of type Encrypted Text.

To add a plug-in:

1. Click ADD PLUG-INS.
2. In the Available Plug-ins list, select a plug-in by selecting the plug-in name.
3. Click DEPLOY.
4. In the plug-ins list, select the Allow checkbox for the plug-in to allow access to the Encryption Service public API.

To delete a plug-in, select the plug-in and click Delete. Appian will prompt you to review the objects that depend on the plug-in before deleting it. Deleted plug-ins can be tracked in the deletions log.

See also:

• Extending Appian
• Encrypted Text

Sign-in page links

The Sign-in Page Links page allows you to add custom links to the sign-in page. The links will appear on the sign-in page in the same order in which they are arranged in the administration console.

The maximum number of links is five and only links that use the http, https, or mailto protocols are allowed.

Sites typeface

The Sites Typeface page allows you to add and preview up to nine custom typefaces for your sites on both web and mobile. Typefaces can only be customized for sites and only one typeface can be used at a time. Custom typefaces can be selected, edited, or removed.

To add a custom typeface:

1. Click Add Typeface.
2. Enter the name of the typeface.
3. Add WOFF, WOFF2, OTF, or TTF files for each weight.

Once you have added these files, you can preview each weight. Additional sets of files, called language groups, can also be added from this dialog.

User start pages

The User Start Pages page allows you to configure which pages users start on when they first log into Appian or if they navigate to the base Appian URL with or without the application context (e.g. acme.appian.com or acme.appian.com/suite). Note that if a user navigates to a specific environment (e.g. Tempo) or page (e.g. a record view), they will not be redirected to their configured start page.

You can add rows to the grid to configure different groups of users to have different start pages. Only public and restricted groups can be selected, not personal groups. If a user belongs to multiple groups that have different start pages configured, his start page will be the highest one in the grid that corresponds to a group that he belongs to.

You can also configure the Default Start Page, which is the start page for all users who don't belong to any of the groups configured in the grid.

To minimize data entry errors, copy and paste start page URLs directly instead of typing them in manually.

Clicking the Save Changes button will cause the configured start pages to take effect in the system.

An audit log captures all historical values in this page.

See also: Appian Administration Console Logging

Authentication

The following pages relate to authentication administration. Unless otherwise indicated in the setting section, these settings do not apply to users who authenticate through SAML.

Appian authentication

The Appian Authentication page allows you to control password strength requirements and password expiration policies.

Password storage

Appian hashes passwords using an industry standard hashing algorithm and only stores the hashed values of passwords. When passwords are entered, they are similarly hashed using the same algorithm, and the result is compared against the stored value.

Password format

The Password Format section allows setting the following:

• Minimum Password Length - The minimum number of characters allowed in a password. The default is 1.
• Minimum Number of Alphabetic Characters - The minimum number of characters from the English alphabet (A-Z and a-z) allowed in a password. The default is 0.
• Minimum Number of Lowercase Characters - The minimum number of lowercase characters from the English alphabet (a-z) allowed in a password. The default is 0.
• Minimum Number of Uppercase Characters - The minimum number of uppercase characters from the English alphabet (A-Z) allowed in a password. The default is 0.
• Minimum Number of Numeric Characters - The minimum number of numerals (0-9) allowed in a password. The default is 0.
• Minimum Number of Special Characters - The minimum number of special characters allowed in a password. The default is 0. Special characters include: ! " # $ % & ' ( ) \* + , - . / : ; < = > ? @ [ \ ] ^ _ \` { | } ~
• Minimum Password Age - The number of days a user must wait between password changes, where one day is defined a 24 hour period and not a calendar day.
• Prevent Reuse of Previous Passwords - How many of their previous passwords should a user not be able to chose as a new password? Valid values are between 0 and 24, inclusive. The default is 1, meaning that the user's current password may not be reused but that other previous passwords may be reused.
• Passwords cannot contain usernames - When checked, the user's password cannot contain their username. Unchecked by default.

The configurations in this section apply only to passwords managed by Appian and do not apply to accounts that authenticate with LDAP or SAML.

For information and details regarding the configuration of the Remember Me Authentication, see also: Remember Me Authentication

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

• Passwords must be at least 7 characters long.
• Passwords must contain at least 1 numeric character.
• Passwords must contain at least 1 letter.
• Passwords must be different than the previous 4 passwords used.

Remember Me

The Remember Me section allows you to enable and disable remember me and set the length of time a user may go between logins. This configuration applies only to users who authenticate with Appian's native authentication or via LDAP and does not apply to users who authenticate against a SAML identity provider.

See also: Remember Me

Session Timeout

• Idle Session Timeout (Minutes): The number of minutes that a user can remain inactive before the system signs them out. Users will be warned five minutes before their session expires. After two more minutes, if the user remains inactive, they will be signed out. The minimum valid value is 15 minutes and the maximum valid value is 480 minutes (8 hours).

Password Expiration

The Password Expiration section allows setting the following:

• Expire Passwords - Should passwords expire after a certain amount of time? The default is that passwords do not expire.
• Maximum Password Age - The number of days after which a password expires and must be reset.
• Warn Users Before Password Expiration - Should users see a warning when they log in when their password is about to expire? The value must be lower than the number you set for Maximum Password Age. The default is that there is no warning period.
• Password Expiration Warning Period - The number of days before a user's password expires where they will be warned about their impending password expiration.
• Expire Temporary Passwords - Should auto-generated passwords, such as those generated when a new user account is created or when an administrator resets a user's password, expire? The default is that they should expire.
• Maximum Temporary Password Age - The number of minutes after which an temporary, auto-generated, password expires and is no longer valid. When a temporary password expires, the user is not allowed to log in and must request that an administrator reset the password. The default is 10080 minutes, which is one week.
• Minimum Password Age - The number of days a user must wait after changing their password before they may change it again. The default is 0. This setting does not affect temporary passwords or the ability for an administrator to reset a user's password.

When a password expires, the user must change the password before they are allowed to proceed past the Appian log-in page.

The configurations in this section apply only to passwords managed by Appian and do not apply to accounts that authenticate with LDAP or SAML.

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

• Passwords expire every 90 days.
• Users are notified regarding password expiration 7 days before it happens.

Initial passwords for Appian Cloud are temporary passwords. The system prompts users to reset their password immediately after logging into Appian Cloud.

Forgot password

The Forgot Password section allows setting the following:

• Enable Forgot Password from Sign-In Page - Should users be able to reset their passwords from the sign-in page? If enabled, users will be able to reset their passwords by clicking the "Forgot your password?" link on sign-in page and following the steps provided.

• Password Reset Link Duration (Minutes) - How long should password reset links be valid? A user following an expired link will need to re-enter their username to receive a new link before they can reset their password. When this value changes, the change is applied retroactively to existing links.

When this feature is enabled, only users that meet the following requirements will be able to reset their passwords:

• The user does not authenticate through LDAP or SAML.
• The user is not deactivated.
• The user's password is old enough to be reset.
• The user has a valid e-mail address.

If either SAML or LDAP are enabled for all users, the Enable Forgot Password from Sign-In Page checkbox will disabled and unchecked because when these authentication features are enabled, Appian does not have control over users' credentials. If, however, only some users authenticate through LDAP or SAML, the feature can be enabled, and the "Forgot your password?" link will appear on the sign-in page for all users.

Use import customization files to change the value between environments with different authentication configurations.

Use of this feature can be audited through the Forgot Password Requests and Password Resets audit logs.

Account locking

User accounts that have difficulty supplying the proper credentials are temporarily locked (prevented from making a login attempt) when the user (or someone attempting to log in as the user) tries too many incorrect passwords. The system does this by keeping track of the number of failed login attempts for each account. The failed login count is reset automatically after some time has passed from the last failed attempt. This prevents the user from accumulating a large number of failed login attempts over a long period of time.

The Account locking section allows setting the following:

• Lock Accounts After Failed Logins - Should accounts be locked after repeated failed login attempts? The default is that accounts are locked.
• Maximum Password Attempts - How many failed login attempts should it take for an account to be locked? The default is 6.
• Password Attempt Reset Duration - How many minutes after a failed login attempt should the counter for the number of failed logins be reset? The interval you specify should be long enough to ensure that a sufficient number of failed attempts accumulate before the counter is reset, should someone attempt to guess at a password by repeatedly submitting random values. The default is 30 minutes.
• Unlock Accounts Automatically - When an account is locked due to failed login attempts, should it be automatically unlocked after a certain time period? If automatic unlocking is disabled, accounts will remain locked until an administrator manually unlocks them. The default is that accounts should be automatically unlocked.
• Lock Duration - When an account is locked due to failed login attempts, how many minutes should it be locked for? The default is 30 minutes.
• Limit Number of Concurrent Sessions Per User Account - Should users only be allowed to have a certain number of sessions active at the same time? The default is that the number of concurrent sessions per user is not limited.
• Maximum Concurrent Sessions - How many sessions should a user be able to have open at the same time before they are no longer allowed to log in again?
• Deactivate Users Who Have Not Logged In Recently - Should users who have not logged in recently be deactivated? The default is that accounts are not deactivated due to inactivity.
• Idle User Deactivation Duration - How many days after their last successful login should a user account be deactivated. Note: This setting also applies to sessions of users authenticating through SAML.

The failed login count is reset if the account is unlocked by an administrator.

When you specify a deactivation interval, that same interval must elapse before user accounts begin to be deactivated. For example, if you specify an inactivity deactivation interval of 90 (90 days) on April 1st, a user account that does not successfully log in between April 1st and June 30th is deactivated. In this scenario, a user account that has not logged in since January 1st also remains active until June 30th, as you did not activate the policy until 90 days after the user account became inactive

User accounts that are deactivated due to inactivity are listed at the INFO level in db_PE_yyyy-mm-dd_hhmm.log in the <APPIAN_HOME>/logs/ directory.

The system user Administrator is never automatically deactivated.

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

• Users who have not logged in are considered inactive after a period of 90 days.

Activity from the Appian Mobile applications does not count towards the number of active sessions a user has and the number of requests from the mobile applications.

See also:

• User Deactivation Logging
• Reactivating Users
• Unlocking Users

Terms of service

The Terms of Service section allows you to set a message on the sign-in page that users must click to accept before entering the system.

• Require Users to Accept Terms of Service Before Logging In - Should users be required to accept terms of service before accessing the site?
• Terms of Service - The message that should appear on the sign-in page.

When you change the terms of service, all Remember Me authentication sessions will be invalidated and users will need to input their username and password the next time they sign-in to Appian.

LDAP authentication

The LDAP Authentication page allows you to configure Appian to authenticate users against an external directory server, like Microsoft Active Directory, via LDAP rather than its native authentication.

• Enable LDAP - Should Appian use LDAP to authenticate users? When this is not selected, all other fields on this page are disabled.
• Servers - The URLs of the LDAP servers to authenticate against. URLs must start with "ldap://" or "ldaps://" and should include the base DN for any query to the LDAP server. Multiple servers will be tried one at a time in the order listed. The base DN must be the same for all servers.
• LDAP Server Connection Timeout - The amount of time, in seconds, that the sytem will wait when trying to connect to an LDAP server before moving on to the next server in the list. The default is 30 seconds. The timeout must be set to a value between 1 and 300 seconds, inclusive.
• Authentication Method - There are two methods of authenticating via LDAP: "Bind as user" and "Search for user then bind as user".
  • "Bind as user" means that Appian will take the username and password provided by a user when they sign into Appian and attempt to bind to the LDAP server with those credentials.
  • "Search for user then bind as user" means that Appian will connect to the LDAP server using a pre-configured set of credentials and search for the user by combining the username they provide with the value of the Search Filter field.
    • Note that if your configuration uses LDAP User Bind to authenticate with the LDAP server (instead of LDAP over SSL), all user entered passwords are sent to the LDAP server unencrypted.
• DN Pattern - A mapping from the username a user enters when signing in to a distinguished name in the LDAP server. Only available when the "Bind as user" option is selected.
• Administrator DN - The distinguished name of an administrative account in the LDAP server that Appian will use to bind to the LDAP server. Only available when the "Search for user then bind as user" option is selected.
• Password - The password for an administrative account in the LDAP server that Appian will use to bind to the LDAP server. Only available when the "Search for user then bind as user" option is selected.
• Search Filter - A mapping from the username a user enters when signing in to an LDAP search query. Only available when the "Search for user then bind as user" option is selected.
• Username Attribute - The name of the LDAP attribute that corresponds to an Appian username.
• E-mail Attribute - The name of the LDAP attribute that holds the user's e-mail address.
• First Name Attribute - The name of the LDAP attribute that holds the user's first name.
• Last Name Attribute - The name of the LDAP attribute that holds the user's last name.
• Create Users Upon Login - If a user exists in the LDAP server but does not exist in Appian, should the user be auto-created the first time they sign into Appian?
• Use lowercase usernames for Appian user lookup - Should Appian lowercase the username that comes back from the LDAP server when looking up the Appian account? Select this option only if all of your usernames only contain lowercase letters.
• Restrict LDAP Authentication to a Specific Group - Should all users authenticate via LDAP or only a subset of users?
• Appian LDAP Group - If only a subset of users should authenticate via LDAP, which group of users should authenticate via LDAP? If a user is a member of the Appian SAML group and the Appian LDAP group, they must authenticate with SAML, not LDAP.

In order to prevent you from locking yourself out of Appian, if your configuration requires that the user you are currently logged in as must authenticate via LDAP then you must successfully test your configuration using the "Test" button before saving it.

It is not possible to configure Appian such that a given user may authenticate with either LDAP or native Appian authentication. Each account may only authenticate against one or the other.

LDAP authentication settings cannot be imported or exported from the administration console.

Maintenance window

The Maintenance Window page allows you to set a period of time to deploy application updates to your environment and write a message to display in a banner at the top of your site. During maintenance windows, all users except for system administrators will be logged out of the site, and a banner will display at the top of your site’s login page for web and mobile.

SAML authentication

The SAML Authentication page allows you to configure Appian to authenticate users against external SAML identity providers, like Microsoft ADFS or Shibboleth, rather than against Appian's native authentication.

• Enable SAML - Should Appian use SAML to authenticate users? When this is not selected, all other fields on this page are disabled.
• Add SAML Identity Provider - Click this button to add a SAML identity provider for users to authenticate against. Follow the instructions here to configure a new identity provider.
• Remember IdP Selection for Non-SAML Users - Enable this setting if you want Appian to use cookies to determine where users should be sent to sign-in.
• Use a Default Sign-In Page vs. Have Users Choose Their Sign-In Page - Determines where unauthenticated users should be taken if they have neither a web address identifier in their url nor a browser cookie.
• Verify My Access - This button only appears when the user you are signed in as authenticates through SAML. When it is visible, it means that before you can save your changes, you must verify that you can still sign in given your changes. Clicking this button will open a new tab, and in that tab attempt SP-initiated sign-in to your identity provider. If you successfully sign-in, you may save your changes.

When configuring your SAML identity provider, it is important to ensure that the metadata file uploaded to Appian is consistent with the configurations defined with the identity provider. Specifically, the entity ID or issuer ID in the uploaded IdP metadata file must match the issuer ID found in the SAML response. Appian requires the entity ID within IdP metadata files to be unique across multiple SAML configurations. Attempting to upload IdP metadata files containing identical entity IDs will result in an error and be prevented by the system. It is not recommended to manually modify an IdP metadata file, prior to uploading to Appian in order to circumvent this restriction, as this may result in users not being able to access Appian.

Additional configuration details and notes

• It is not possible to configure Appian such that a given user may authenticate multiple ways. That is, each user can authenticate through a single identity provider, or native Appian authentication, or LDAP. If a user is in multiple SAML authentication groups, the highest identity provider in the list takes precedence.
• Starting a process model as web service requires using Appian's native authentication and is therefore not available to users who are configured to authenticate via SAML.
• SAML authentication settings cannot be imported or exported from the administration console.
• A user configured to authenticate using SAML cannot be used to call Appian web APIs.

Security

• Appian signs its assertions using the SHA-1 hashing algorithm. Some identity providers, such as Microsoft ADFS, require you to specify this when configuring it to integrate with Appian.
• Appian supports signed, encrypted SAML assertions up to the AES-256 standard. In order to make use of this capability, the environment must be running on an Appian Cloud instance. Otherwise, self-managed environments will need to be running OpenJDK 8 or have the JCE security jar installed for the Oracle Java JDK.

Related links

For more information see, SAML Authentication.

Users

The Users page allows you to:

• Create a new user
• View an existing user and update their information and avatar
• Rename an existing user
• Deactivate and reactivate users
• Reset user passwords
• Unlock user accounts
  

Users cannot be imported or exported from the administration console.

See also: User Management

Web API Authentication

This page allows you to manage API keys and OAuth 2.0 clients, which can be used to invoke Appian Web APIs.

API keys

The API Keys tab allows you to create and manage API keys and Service Accounts, which can be used to invoke Appian Web APIs. This page allows you to:

• Create a new API key and/or service account
• Deactivate and reactivate API keys
• Permanently delete API keys

Creating an API key

To create a new API Key:

1. From the API Keys tab, click Create.
2. Enter a unique Description.
3. Select a Service Account to associate with the key. To create a new service account, click Create Service Account and enter a username.
   • Note: "Service Account" will automatically be added to whatever username you enter. See Service accounts.

   

4. Copy the API Key and store it externally. Appian will never show the value of the API key a second time.

Managing API keys

There are three ways to invalidate an API key:

• Delete an API key - This option is permanent. Once an API key has been deleted, it can never be restored.
• Deactivate an API key - For something more temporary, you can deactivate an API key. Inactive API keys can be reactivated in the future to make them to work again.
• Remove the associated service account from the Service Accounts system group - This will cause all API keys and OAuth 2.0 clients associated with the service account to stop working. However, if the service account is placed back in the Service Accounts system group, the associated keys and clients will start working again.

OAuth 2.0 Clients

The OAuth 2.0 Clients tab allows you to create and manage OAuth 2.0 Clients and Service Accounts, which can be used to invoke Appian web APIs with the OAuth 2.0 Client Credentials grant. This page allows you to:

• Create a new OAuth 2.0 client and/or service account
• Deactivate and reactivate OAuth 2.0 clients
• Permanently delete OAuth 2.0 clients

Creating an OAuth 2.0 Client

To create a new OAuth 2.0 client:

1. From the OAuth 2.0 Clients tab, click Create.
2. Enter a unique Description.
3. Select a Service Account to associate with the client. To create a new service account, click Create Service Account and enter a username.
   • Note: "Service Account" will automatically be added to whatever username you enter. See Service accounts.

   

4. Copy the Client ID, Client Secret, and Token Request Endpoint values and store them externally. Appian will never show the value of the Client Secret a second time, so that value is particularly important to copy.

Managing OAuth 2.0 Clients

There are three ways to invalidate an OAuth 2.0 client:

• Delete an OAuth 2.0 client - This option is permanent. Once a client has been deleted, it can never be restored.
• Deactivate an OAuth 2.0 client - For something more temporary, you can deactivate an OAuth 2.0 client. Inactive OAuth 2.0 clients can be reactivated in the future to make them to work again.
• Remove the associated service account from the Service Accounts system group - This will cause all API keys and OAuth 2.0 clients associated with the service account to stop working. However, if the service account is placed back in the Service Accounts system group, the associated keys and clients will start working again.

Service Accounts

If you need to create a new service account, you can easily do so by clicking the plus icon to the right of the Service Account picker on the API key creation modal or the OAuth 2.0 client creation modal. This prompts you to provide a username.

Service accounts should be created in each environment with the same username and placed in the same groups so that permissions can be promoted to higher environments.

The created service account will have its first name set to the selected username and its last name set to "Service Account". It will be automatically assigned the Service Account role.

Existing users can be converted to service accounts by placing them in the Service Accounts system group. When a service account is removed from the system group or deactivated, all API keys and OAuth 2.0 clients associated with that service account cease to work. Although they won't work, these credentials will continue to exist until they are manually deleted.

DevOps

The following pages relate to features that support DevOps.

Deployment

The Deployment page allows you to manage the following settings:

Allow test values to be imported with design objects

When enabled, test values saved in interface and expression rules are imported along with those objects. When not selected, interfaces and expression rules have their test values removed on import.

Allow database schema changes through data stores

When enabled, automatic database schema updates will occur on data type update and data store import for appropriately configured data stores. When disabled, data stores' automatic database schema update configurations will be ignored, and automatic updates will never occur.

Health check

The Health Check page allows you to set up, schedule, and run Health Checks on your Appian environment.

Settings

Health Check Settings are grouped by three sections: General, Automatic Upload, and Scheduling.

A - General

To help Health Check establish the correct risk level for various findings, specify whether your environment is a production environment.

The Health Check Viewers system group allows users to access the Health Check report from a News post and via email notifications. System administrators will always have access to the report from the Admin Console.

B - Automatic upload

Appian recommends enabling automatic upload to make your Health Check process more efficient. Automatic upload allows your environment to directly submit the data collection zip file to Appian Community when it is ready for analysis.

To enable automatic upload, Health Check credentials for Appian Community are required. The same credentials can be used across multiple environments within your organization. You can request credentials from Appian Technical Support by opening a support case. Once you have your Health Check credentials, enter them in the Automatic Upload section.

If you previously configured third-party credentials for the Health Check plug-in, they are automatically detected and transferred over as Health Check credentials for the Settings page.

If you enable automatic upload, a data review will be required for the first Health Check run in each environment. During that review step, you will have the option to select Autoapprove this step for future runs and skip data reviews for future runs.

System administrators can disable autoapprove from the Automatic Upload section at any time after their first Health Check run.

If automatic upload is not enabled, a system administrator will need to manually download the data collection zip file, and upload it to Community for analysis during each run.

C - Scheduling

After enabling scheduling, you will be asked to provide the date and time of your first run, as well as how frequently you would like Health Check to run.

Appian recommends regularly scheduling Health Check, and running it during non-business hours in a production or active environment, as it may increase system load and degrade performance. You should also take into consideration the time zones of your primary Appian users when scheduling Health Check.

Health Check will run within a 10 minute window of the scheduled time. For example, if you schedule Health Check to run at 12:00 AM, it could start as late as 12:09 AM.

Landing page

1. Settings button: Returns you to the Settings page.
2. Run Now button: Immediately starts a Health Check run.
3. History section: Displays information about your previous 50 Health Check runs.
   • Each run will show:
     • When the run started and how it was kicked off.
     • How long data collection took, in minutes.
     • Whether or not it was a scheduled run.
     • The final status of the run (completed, canceled, or failed).
   • For runs when automatic upload was enabled, you will see additional details such as:
     • When the data review was approved and who approved it.
     • The number of days in the analysis period (the period of time covered by the report).
     • A link to download the resulting Health Check report. Reports are only available for the most recent 25 runs.
   • For runs when automatic upload was disabled, reports will not be available for download from within the grid.
4. Download Last Run’s Zip button: Downloads the data collection zip file that Health Check generated for your latest run. Any edits that you may have made to the zip file before submitting it for analysis will not be reflected in this download. This option is disabled when the latest run is canceled or encounters an error.

Infrastructure

The Infrastructure page displays all the Appian environments in your organization and lets you control how those environments interact with each other. For example, you can let developers in your development environment compare and directly deploy application changes to their test environment.

Environments

The section displays all connected environments, their name, URL, direct deployment status, and connection status. You can also select an environment to view the last action, modifier, and modified date.

System administrators can enable and disable the connection with each environment. Both environments must have their connections enabled to leverage infrastructure capabilities, such as compare and deploy. If either environment disables their connection, all infrastructure capabilities between the two environments are disabled. For example, the dev environment must be added to the infrastructure of the test environment and vice versa for the connection to be fully enabled.

Icon	Connection Status
	Enabled: this is the only status where infrastructure capabilities can be leveraged
	Disabled by remote environment
	Disabled by current environment
	Disabled by both environments
	Connection error with connection enabled by current environment
	Connection error with connection disabled by current environment

Managing environments

To add an environment:

1. Click Add New Environment and enter the URL for a remote environment.
2. Click Send Request. A request will be sent to the environment system administrator and a notification about the request will display on the infrastructure page.

Outgoing connection requests can be withdrawn at any time. Once the request is sent, system administrators will receive an email that links them to the infrastructure page. They can view the incoming connection requests and take action on them. Incoming connection requests will time out after 7 days if no action is taken on them.

To allow connection from Appian:

1. Select the environment and select Allow connection from [environment name].
2. Click Save Changes.

To enable direct deployments from Appian:

1. Select the environment and select Enable direct deployments from [environment name].
2. Configure your direct deployment options in the Direct Deployments section.
3. Click Save Changes.

When enabled, this environment will receive deployment requests from the selected environment in this infrastructure. A deployment can include object, database, and plug-in changes, which will be tracked in the deployments view on both environments. Appian recommends configuring which specific environments can deploy to higher environments, such as Production. For example, you should allow application administrators on the Test environment to deploy to Production. But you wouldn't necessarily allow application administrators on the Development environment to deploy to Production. Disabling direct deployments will block direct deployments without affecting the ability to monitor performance metrics or compare applications.

Removing an environment from the current infrastructure will remove the environment from the remote environment's infrastructure as well.

To remove an environment:

1. Select the environment and click Delete.
2. Click Remove.

Using mutual authentication

If your environment leverages mutual authentication, you will need to upload your current environment’s SSL certificate to each of its connected environments. In addition, you’ll also need to ensure that your current environment has the SSL certificate from each of its connected environments. To do this, upload the trusted server certificates in the Admin Console. For troubleshooting information, refer to the Knowledge Base.

External deployments

When external deployments are enabled, incoming deployments to the current environment can be triggered programmatically via the deployment APIs. When disabled, any calls to these endpoints will fail with an HTTP 403 status code, indicating that the environment is not accepting deployments via these APIs.

In order to authenticate an external deployment request, you must have an API key and corresponding service account. These can be created and managed from the Web API Authentication page. The appropriate service account should be selected in the Authenticate As field, which will result in its associated API key being passed as part of the API request

Deployment settings

This section displays settings that apply to incoming direct and external deployments from all environments that have been added to this environment's infrastructure.

After enabling direct or external deployments from other environments, you are required to select a system administrator user in the service account role to act as the deployer in the Deploy As picker. This user will appear as the Last Modifier for all objects in the deployment.

You can also allow users to directly deploy plug-in and database changes. Select Allow deployments with plug-ins to allow the current environment to receive plug-in changes through direct deployments. Select Allow deployments with database scripts to allow this environment to receive database changes through direct deployments.

To add deployment approval for your deployment process, select the Require Review option and specify a reviewer group. In addition to system and application administrators, this group can approve or reject deployments.

Integration

The following pages relate to integration administration.

Certificates

There are two types of SSL certificates that can be managed in the Admin Console: Client Certificates and Trusted Server Certificates.

Client certificates

Some web services require transport-level client certificate authentication when setting up an SSL connection. The Client Certificates tab of the Certificates page allows you to expose certificates for use by the HTTP integration and HTTP connected system objects, the Call Web Service smart service, the webservicequery() expression function, and the webervicewrite() expression function.

The main view of the Client Certificates page is a grid view of all of the client certificates in the system. Initially the grid will be empty. Click New Client Certificate to upload a new certificate. The certificate must be formatted as a PEM file. If the certificate is protected by a password you should enter the password in the password field. This password will not be stored. The certificate will be stored in an encrypted format in the Appian data source.

There is no way to download a certificate from this page. Store a copy outside of Appian as well as uploading one here.

All modifications result in an audit log message with the username of the user who made the change, the previous values, and the new values.

Client certificates cannot be imported or exported from the administration console.

Trusted server certificates

Some web services, such as those that utilize self-signed or internal SSL certificates, require an administrator to explicitly trust certain server certificates for authentication. The Trusted Server Certificates tab of the Certificates page allows administrators to upload a server certificates that should be trusted by HTTP integrations, connected systems, the Call Web Service smart service, the webservicequery() expression function, and the webervicewrite() expression function.

The main view of the Trusted Server Certificates page is a grid view of all of the trusted certificates that have been added through Trusted Server Certificates grid. Initially the grid will be empty. Click New Trusted Server Certificate to upload a new certificate. The certificate must be formatted as a PEM file. The certificate will be stored in an encrypted format in the Appian data source.

There is no way to download a certificate from this page. Store a copy outside of Appian as well as uploading one here.

All modifications result in an audit log message with the username of the user who made the change, the previous values, and the new values.

Trusted server certificates cannot be imported or exported from the administration console.

Data sources

The data sources page lets you integrate Appian with external databases using a JDBC connection by adding, updating, and removing named connection configurations called data sources. These data sources are available for designers to use in their applications through data stores and the Query Database smart service.

A data source consists of the following fields:

• Name - The name of the data source that will appear in the Appian design interfaces, such as the data store designer. It is recommended that this name begins with "jdbc/". If you are using multiple environments, a data source with the same name must be created in each environment.
• Type - The type of database you wish to connect to.
  • Note: If you are using Amazon Aurora, select the type of database that matches your Aurora version. If you are using Aurora MySQL, choose MariaDB instead of MySQL, since Amazon recommends using the MariaDB driver. If you are using Aurora PostgreSQL, simply choose PostgreSQL.
• Username - The username for connecting to the data source
• Password - The password for connecting to the data source. The password will be stored in an encrypted format, not in plain text.
• Connection String - The URL for the data source. Should include the hostname, port, and database name of the data source, but the exact syntax will vary by database type. If you do not know the URL for the data source, consult your database administrator. Please refer to Configuring Relational Databases page for special considerations for individual databases while configuring them for use with Appian.

You cannot create a data source with the same name as the Appian data source, as specified in the conf.data.APPIAN_DATA_SOURCE property in custom.properties.

See also: Business Data Sources

Document extraction

Configure options in this section of the Administration Console to control which document extraction vendors are enabled on your environment. Currently, Appian offers document extraction powered both by Appian built-in services and by Google Document AI.

Using Appian services

Availability of Appian's built-in document extraction capabilities varies based on your site's compliance requirements:

• Appian Cloud SOC2 customers have these services enabled by default.
• Appian Cloud HIPAA and PCI-DSS customers can enable these services (disabled by default).
  • If you choose not to enable these services, you can still use other built-in document extraction features when Appian is selected as the preferred vendor in a document extraction process:
    • Searchable PDFs: selection tool and positional extraction.
    • Fillable PDFs: key-value pair extraction, selection tool, positional extraction, and checkbox extraction.
• Self-managed customers and Appian Cloud FedRAMP customers don't have access to these features at this time.

You can review Appian Cloud services compliance statements to ensure that it aligns with your organization's security requirements.

Using Google services

In order to use certain Document Extraction features, you need to enter your Google Service Account key information in the Admin Console > Document Extraction page.

The required information is in the Google Service Account Key file, which is generated when the service account key is created. These keys will be used for all instances of the Doc Extraction smart services.

How to get a Google service account key file

If you are using Appian AI, contact your Appian administrator for the Google Service Account Key JSON file from the License Management section of Appian Community.

Otherwise, to create the Service Account Key file:

1. Ensure APIs are enabled - in the Google Cloud Console, navigate to APIs & Services > Library - see Google Cloud docs on enabling APIs.
   1. Google Cloud Storage JSON API
   2. Cloud Document AI API
2. Generate a Google Cloud Storage Bucket - see the Google Cloud documentation on creating storage buckets
3. Create Google Service Account with storage.objects.create and storage.objects.list permissions. In the Google Cloud Console, navigate to APIs & Services > Credentials page - see the Google IAM documentation for more information on creating and managing service accounts.
4. Generate a Service Account Key - to use Google Service Account authentication, you will need a service account key for your service account. This file should be download in JSON format. To learn about creating and managing service account keys, see the Google IAM documentation on creating and managing service account keys

The following Google Cloud Document AI keys are in the Google Service Account key JSON file that is generated when the service account key is created.

• Project ID - Found in the Google Service Account file
• Private Key ID - Found in the Google Service Account file
• Private Key - Found in the Google Service Account file
• Client Email - Found in the Google Service Account file
• Client ID - Found in the Google Service Account file
• Destination Bucket - The name of the Google Cloud Storage Bucket to upload the file to. The Google Service Account must have write access to this bucket. For example: storage-bucket-0000000000
• Source Bucket - The name of the Google Cloud Storage Bucket to upload the file to. The Google Service Account must have read access to this bucket. For example: storage-bucket-0000000001
• Compute Region - The region that Google will store and process the resources for your project. The following regions are currently supported: us, eu.
• Test Connection - Uses the provided configuration information to connect to the target system. Returns success or error with details.

See also:

• Document Extraction
• Appian AI

Email

The Email page allows you to enable or disable the ability for Appian to send email.

Embedded Interfaces

The Embedded Interfaces page allows you to manage origins and themes for embedding interfaces on external web sites.

Origins

The Origins section allows you to add and remove from the list of hosts that are allowed to make cross-origin resource sharing requests to your Appian site. If an Appian interface is embedded on a web site that uses a different host than Appian, that host must be added to the allowed origins list. Origins should be entered using the host as it is typed in the browser address bar with the port (if it's different than the protocol default) but without the protocol, like server.example.com or server.example.com:8080.

By default, the list is empty. The prevention of unauthorized cross-origin requests is an important part of web application security, so only trusted hosts should be added to this list.

Adding or removing a host results in an audit log message with the username of the user who made the change, the previous list of allowed hosts, and the new list.

See also: Embedded Interfaces

Themes

The Themes section allows you to configure any number of themes with custom font and color styling. A theme can be optionally applied to the interfaces that are embedded in an external web page. This allows custom styling of embedded interfaces in order to make them more consistent with the host web page.

Note that themes can only be applied to embedded interfaces. Learn more about Tempo branding and sites branding.

All modifications to themes result in an audit log message with the username of the user who made the change, the previous values, and the new values.

See also: Themes for Embedded Interfaces

HTTP proxy

The HTTP Proxy page allows you to configure a proxy server for outgoing HTTP and HTTPS connections. The proxy is used by following integration features:

• HTTP, OpenAPI, and Pre-Built Connected Systems
• Integrations
• Call Web Service Smart Service
• webservicequery()
• webervicewrite()

Property	Description
Enable HTTP Proxy	Should Appian use an HTTP Proxy? When this is not selected, all other fields on this page are disabled.
Host	The hostname or IP address of the proxy server.
Port	The port of the proxy server.
Do not use the proxy server for the following hosts	A list of hostnames or IP addresses. Requests that match hosts in this list will not use the proxy server. Wildcards (*) are supported, e.g.: *.google.com will match www.google.com and docs.google.com.
Use proxy authentication	Does the proxy server require authentication? When this is not selected, the Username and Password fields are disabled.
Username	The username used for proxy authentication.
Password	The password used for proxy authentication.

Legacy web services

The Legacy Web Services page allows you to manage processes exposed as web services. The interface for configuring legacy web services opens in a new browser tab.

Legacy web services cannot be imported or exported from the administration console.

Logging

This page allows you to configure logging for integrations to facilitate troubleshooting.

Integration Trace Logging

This section controls the integration_trace.csv log. When enabled, Appian will log tracing information about integrations. For example: if the request was successful or if it logged out.

See the Logging page for the fields that are captured.

HTTP Request/Response Logging

This section controls the integration_req_resp_activity.log log. When enabled, logs the raw HTTP request and response messages for integration objects that have logging enabled. Developers can turn on logging for any integration object that uses an HTTP or OpenAPI connected system.

See the Logging page for more information on the HTTP request/response logs.

Microsoft Office

This page allows you to configure Appian's Task Viewer Add-in for Microsoft Outlook.

• Enable Integration - This box must be checked to use the Task Viewer Add-in. When checked, an unauthenticated endpoint, /suite/integrations/office/outlook, that serves up the content to embed in Outlook is enabled. The endpoint can only serve up content when embedded in Outlook and does not expose sensitive data to unauthenticated users.
• Download the site-specific add-in manifest link - Click this link to download an add-in manifest file that can be uploaded to Office to enable the Task Viewer Add-in.
• Follow the instructions for configuring Outlook link - Click this link to view the instructions for enabling the Task Viewer Add-in.

Third-party credentials

The Third-Party Credentials page allows you to manage credentials to external systems. These credentials are stored in the Secure Credentials Store and can be used by authorized plug-ins through the public API as well as by built-in smart services and functions such as the Call Web Service smart service and the webservicequery expression function.

The main view of the Third-Party Credentials page is a grid view of all of the configured sets of credentials. Initially the grid will be empty. Click Create to create a new entry.

A form with the following fields will display, allowing for the creation of a new set of credentials for connecting to an external system.

• Name - The name of the third-party credentials entry. This name represents the external system to which the credentials will be used to authenticate. The name given here is displayed anywhere that this set of credentials can be selected, such as on grid on the main page of the admin page, in the "Predefined Credentials" drop-down in the Call Web Service Smart Service, and on the Third-Party Credentials settings page available to end-users.
• Key - The key field is auto-generated and not editable. The key is generated based on the given name. The key does not change when the credentials set is renamed. The key is used when accessing the credentials through the Secure Credentials Store public API and used as a reference to the credentials when inspecting the audit log for the Secure Credentials Store.
• Description - A short description of the credentials set and/or the external system.
• Plug-in List - The list of plug-ins that are authorized to use this set of credentials. When deploying a plug-in that uses the Secure Credentials Store API, that plug-in must be added to this list for each set of third-party credentials that it will be allowed to access. The input will auto-complete and allow selection of a deployed plug-in as you type the name or plug-in key of the plug-in. Any plug-ins that were previously added to the list, but have since been removed from the system, will appear in the list as the plug-in key rather than the plug-in name. These plug-ins may be safely removed if you know that they will not be re-deployed to the system.
• Credentials - The credentials section of the form allows you to define the fields of the credentials (e.g., "Username" and "Password") as well as the site-wide values for these fields. Once fields are defined, a checkbox allows you make these fields available to end-users on the Third-Party Credentials settings page, so that they can store their own personal credentials that are used to connect to the external system. For each set of a credentials, the designer of an application has the ability to select whether to use the site-wide credentials (for use cases where there is a single integration user), or use the per-user credentials (for use cases where the individual's access rights to the external system are important). Using an individual's credentials is only possible when that user is logged in and acting in the system. When configuring credentials for the first time, the section will be empty except for an "Add field" link. Clicking the link will display a grid with the following columns:
  • Field name - The display name of the credentials field (e.g., "Password"). This name will appear as the label of the input in the Third-Party Credentials settings page for end-user to enter their credentials. When accessing the credentials through the Secure Credentials Store Public API, the key for this field will be the same as the given field name, except all lower-case, with dots instead of spaces.
  • Key - The key field is auto-generated and not editable. The key is generated based on the given name. The key does not change when the field is renamed. The key is used when accessing the credentials through the Secure Credentials Store Public API.
  • Value - This is the value for the credentials field that will be used when a designer chooses to use the site-wide credentials rather than per-user credentials.
  • Mask - This Yes/No toggle is only available when the checkbox to allow individuals to set their credentials has been checked. When selected, the value for this field will appear as masked in the Third-Party Credentials settings page for end-users.
• Test Connection - The test connection section of the form allows you to test the values for site-wide credentials. Provide an expression that returns true if the connection was successful. As a best practice, define the expression in a rule and use the rule here. When testing the connection, the expression only has access to the current credentials on the form and you must use the unique identifier key as generated to retrieve the credentials from the Secure Credentials Store. If testing using a function that is provided in a plug-in, that plug-in must be in the authorization list.

Deleting individual credentials fields will cause all site-wide and per-user values for that field to be deleted. Deleting a set of third-party credentials from the grid on the main page will cause all site-wide and per-user values for the entire set of credentials fields to be deleted.

All credential changes result in a audit log message with the username of the user who made the change, the previous values, and the new values.

See also:

• Secure Credentials Store
• Settings Page

Monitoring

The following pages relate to monitoring your Appian installation.

Monitoring information cannot be imported or exported from the administration console.

Current user activity

The Current User Activity page allows you to see which users are currently active on your site.

User activity is stored for 1 hour and only the most recent 1000 entries are displayed.

When a user logs out of the system, they are removed from the list of recent activity.

It is possible for the same user to appear in the list twice if they are connected from two different browsers or mobile clients.

Document reports

The Document Reports page shows the following usage information about documents in the system:

• General Statistics - The total number of uploaded and downloaded files as well as the total disk space used by documents (excluding versions).
• User Statistics - Information about the number of users that have uploaded and downloaded files in the system.
• Total Last 10 Days - The number of uploads and downloads that have occurred over the previous ten days.

Note that user avatars are stored as documents, so views of user images are counted as downloads.

Import history

The Import History page allows you to see all the imports that have occurred on the system during the last 30 days. This includes imports from:

• Appian Designer
• Appian Administration Console
• ImportExportService

NOTE: please refer to the Public API for more information

Clicking the document icon on the last column of the grid will download the import log for the corresponding import.

Rule performance

The Rule Performance page allows you to see the historical performance of all of the rules in the system. It contains a table of rule name, the number of times that rule has been executed, the average execution time, the minimum execution time, and the maximum execution time.

A moving window of thirty days of performance metrics are gathered and stored as end users execute the rules. The evaluation times recorded do not include the evaluation of the rules when they are executed in Appian Designer.

Clicking on the name of a rule will bring up more details on the performance of that rule, including graphs of the performance over time. These graphs are the same as the ones found in the historical performance trends in the performance view.

This page contains performance data for rule objects, including expression rules, interfaces, query rules, integrations, and decisions.

Import and export of admin console settings

All settings can be imported and exported from the Admin Console, except for settings on the following pages:

• API Keys
• LDAP Authentication
• SAML Authentication
• Infrastructure
• Certificates
• Legacy Web Services

In addition, plug-ins themselves cannot be imported or exported - export is only supported for the associated Encryption Service setting.

Export

The Export Settings dialog can be accessed via the Export button in the administration console header.

The Export Settings dialog shows a list of all available admin console settings available to be exported. This grid can be filtered by clicking on the Show Filters link; settings can be filtered on category or modified date.

After performing an export, the confirmation dialog will provide a link to the administration console package. If the exported settings can be parameterized, an import customization file will also be generated and available to download from the confirmation dialog.

Import

The Import Settings dialog can be accessed via the Import button in the administration console header. Administration console settings and application objects can be tightly coupled. Because of this, Appian allows you to import an application package and an administration console package together.

These packages will be included in a single import, so any dependencies between them are identified and properly resolved. Dependencies include:

• User start pages secured to groups
• Data stores pointing to a data source by its JDNI name
• Embedded interface themes referencing design objects in the Page Background Color or Accent Color fields
• Third-party credentials referencing design objects in the Test Connection field

You can choose to import a patch instead of an application by selecting the Patch option on the Import Settings dialog. When uploading a patch package, you will be required to select the application to which the patch objects should be added. Administration console settings are never added to an application.

Setting-specific behavior

Data Sources

During import, Appian tests the connection of the data source, if a connection cannot be established successfully, the data source will fail to import. This connection test also happens during inspection.

Health check

Health Check must be set up and enabled on an environment before any imported Health Check configurations can take effect.

All Health Check Setting properties are available for import and export with the exception of members of the Health Check Viewers group and whether data reviews are autoapproved. By default, data reviews are required in each environment. To enable autoapprove for data reviews, you will need to do so manually on each environment.

When Health Check Settings are exported, the Service Account credential fields are left blank. These fields can be edited in the Health Check properties file and imported into a target environment. Note that on import:

• When the automatic upload field is set to true, a Service Account username and password must be provided.
• When the automatic upload field is set to false, any Service Account credentials provided in the properties file, or existing credentials on the target environment, will be removed.

Permissions

To export and import Quick App Creator permissions, export the Quick App Creators group.

Note: Member groups are included when exporting a group, but individual user members are not. See also: Groups

Plug-ins

The list of Encryption Service public API permissions for all plug-ins shown on the Plug-ins page can be exported as one item. For example, if you have plug-in X that has permission to use the Encryption Service and plug-in Y that doesn't, both permissions would be set during import if the setting was included in your import package. On import into the target environment, only the plug-ins that are listed in the package are updated. You may have more plug-ins in the target environment, and their Encryption Service configurations are not updated.

Appian recommends that if you are sharing an admin console package with environments where you have no knowledge of the deployed plug-ins, you should not include this setting as it might overwrite a plug-in's permissions.

Third-party credentials

When importing a set of third-party credentials onto a target environment for the first time, the credential field values can be configured in one of two ways:

• Set the values in the import customization file
• Manually set the values after import

Updating the set of third-party credentials via import will not reset any per-user credentials that a user has stored. These will only be removed if that specific credential field has been deleted from the third-party credentials.

Third-party credentials may reference plug-ins. The referenced plug-ins may be deployed before or after the third-party credentials, and the reference to the plug-in name will be preserved. Appian recommends that plug-ins are deployed before importing your applications and admin console settings.

User start pages

If one of your start pages points to a specific record or action, this URL will not be the same across environments. Be sure to confirm the URL is correct for these pages after import.