Frequently Reused Appian Components

joel.larin — Thu, 13 Jun 2024 13:22:56 GMT

Current Revision posted to Guide by joel.larin on 6/13/2024 1:22:56 PM

Skills Covered

A key benefit of the Appian platform is that it allows you to create and store development and design objects so you can easily retrieve them for future use. A developer needs to consider reuse in the way a component is built. To enable effective reuse, a minimum of parameterization is required. While this will add a small amount of additional effort, it is easily outweighed by efficiency gains throughout the application development life cycle. The following five components are commonly found in Appian projects, and therefore make excellent candidates for reuse.

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Data capture, storage and retrieval are key functions of any application. The storage and retrieval of data to and from the database is efficiently managed through query rules. The functionality supporting the retrieval or update of data to a database table is one of the most common parameterized expressions you will find in any application.

To create more reusable queries, first build a query object or query expression object that returns all columns for a given row. Then add all major columns as filters and configure the query to ignore empty filters, which is done by using a!logicalQueryExpression. Once the object is created, you can source local variables within interface or expression objects using the general query object with desired filter criteria.

Interface Components

Appian delivers out-of-the-box drag and drop functionality of countless components which allows you to create great user interfaces. However developers often take it a step further in fine-tuning layout to the specific needs of the end-users. These needs can relate to how data is graphically presented on-screen (e.g. branding, fonts, graphs, date formats) as well as how the data is manipulated before presented on screen (e.g. accumulation, permutation, classification). Both categories of fine-tuning, the interface components and business rules, once configured can be easily reused by making them available through a shared components application.

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Appian offers a robust set of frameworks, support applications, utilities and third-party integrations designed to streamline application development. Examples include audit, comments, user and group management, metrics capture, and reporting.

Simply download the application from the AppMarket and import into your environment through the Admin Console. Once the application is uploaded, you are free to use the packaged objects anywhere in your application! For the full list of available applications and plug-ins, click here.

Internationalization

The Appian design and admin interfaces are available out-of-the-box in multiple languages. Applications developed as part of a project, along with their user interfaces, are built from scratch. Therefore, support for multiple languages is optional and depends on business requirements. Backend functionality, a multi-language framework, is set up once and shared across the Appian platform. As of version 23.4, applications use the Translation Set Object to enable multi-language support.

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

Platform internationalization is handled in the Administration Console under the Internationalization tab. You can select the languages available to users and the primary locale of the site. Users will default to the primary language and can change their language to any enabled language through the settings. For details on how to enable additional languages for your site, see Internationalization Settings.

If multiple languages are enabled, users can switch the language in which they see the Appian interface. For instance, if Russian is enabled, users can display Appian in Russian or English. The following elements will be translated into different languages:

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific can be internationalized as part of application development. Application internationalization is enabled through the Translation Set Object. This object is a collection of translation strings that you can use to translate user display text, such as headers and labels, in interfaces and expressions. It is possible to add translation strings in bulk by generating them directly from an interface, converting hard-coded labels into translation strings.

When all interfaces are included in the translation set, it can be exported in a spreadsheet format for professional translators to provide the values in all other locales, and imported back once it’s populated. Then, switch your user profile settings to a different language/locale to enable viewing your application in that language/locale.

Special Considerations for Implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

By implementing these internationalization practices, you can ensure that your application is accessible and user-friendly for a global audience, meeting diverse language and locale requirements effectively.

Business Processes

A key architectural design principle in building Appian applications is to compartmentalize functional process steps. This is not only good for efficient system memory management, but also allows for reuse of repetitive business logic. To leverage a reusable process, simply add it to your business workflow as a subprocess within that process model.

Review and approval is a typical business process that can be applied to multiple areas. A frequently seen example occurs in loan origination processes within the banking industry. For some banks, different types of loans (eg. secured or unsecured) both go through the same or similar approvals. Through parameterization of the business process components the approval functionality can be efficiently reused across the platform.

Authentication

Many Appian customers configure their higher environments with SAML Single Sign-On (SSO) or LDAP configurations to leverage already existing identity providers. Authentication configurations are done at the platform level, meaning that it can be reused across all applications in a given environment with minimal additional configurations.

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 19:12:02 GMT

Revision 29 posted to Guide by joel.larin on 6/11/2024 7:12:02 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Special Considerations for Implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 19:11:29 GMT

Revision 28 posted to Guide by joel.larin on 6/11/2024 7:11:29 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Special Considerations for Implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 19:01:07 GMT

Revision 27 posted to Guide by joel.larin on 6/11/2024 7:01:07 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Other considerations for implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 18:52:59 GMT

Revision 26 posted to Guide by joel.larin on 6/11/2024 6:52:59 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Other considerations for implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 18:51:44 GMT

Revision 25 posted to Guide by joel.larin on 6/11/2024 6:51:44 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Other considerations for implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 18:51:09 GMT

Revision 24 posted to Guide by joel.larin on 6/11/2024 6:51:09 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Other considerations for implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

joel.larin — Tue, 11 Jun 2024 18:49:53 GMT

Revision 23 posted to Guide by joel.larin on 6/11/2024 6:49:53 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Make Applications Available in Multiple Languages

You may need to build an application that will be used by people speaking different languages. There are two levels of internationalization that need to be handled:

Platform level: This includes all base-product words, such as the names of the five tabs, numerical value, and date formats.
Application level: This includes all application-specific words, such as record names and field labels on an interface.

Platform Internationalization

The five tabs and any base-product words in the Tempo interface, including:
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News, and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Note that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Other considerations for implementation

If a language is not supported and available out-of-the-box within the Internationalization Settings of the platform environment at the Admin Console, Appian offers an Internationalization Application plugin and the Load Resource Bundle plugin on Appian AppMarket.
Object names cannot be internationalized, for example, Groups, Record Types, Knowledge Center, Documents, etc.
Object internal components with expression-backed labels can be internationalized, for example, Record List View User Filters, Process Model Display Names, etc.
Reference data coming from the database will require translation via the Load Resource Bundle plugin. Instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

Appian Max Team — Tue, 23 Apr 2024 13:11:30 GMT

Revision 22 posted to Guide by Appian Max Team on 4/23/2024 1:11:30 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

The Appian design and admin interfaces are available out-of-the-box in multiple languages. The application that is developed as part of a project, and its included user interfaces, are built from scratch. Hence, support for multiple languages is optional and depending on business requirements. Backend functionality, a multi-language framework, is set up once and shared across the Appian platform. Appian offers an Internationalization Application on Appian AppMarket to improve performance and effectiveness of designing applications for multiple languages.

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

Platform internationalization is handled in the Administration Console in the Internationalization tab. You can select the languages available to the users, and primary locale of the site. Users will be defaulted to the Primary Language to begin with, and will be able to change their language to any language enabled through the settings. For details on how to enable additional languages for your site, see Internationalization Settings.

If multiple languages are enabled, users will be able to switch the way they see the Appian interface. For instance, if Russian is enabled, this will allow users to display Appian in Russian or English. The following will be translated into different languages:

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 16:35:29 GMT

Revision 21 posted to Guide by Kim Day on 10/31/2023 4:35:29 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 16:09:02 GMT

Revision 20 posted to Guide by Kim Day on 10/31/2023 4:09:02 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 15:05:40 GMT

Revision 19 posted to Guide by Kim Day on 10/31/2023 3:05:40 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 15:05:09 GMT

Revision 18 posted to Guide by Kim Day on 10/31/2023 3:05:09 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: Delivery, design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 15:01:02 GMT

Revision 17 posted to Guide by Kim Day on 10/31/2023 3:01:02 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design patterns

Frequently Reused Appian Components

Kim Day — Tue, 31 Oct 2023 14:59:11 GMT

Revision 16 posted to Guide by Kim Day on 10/31/2023 2:59:11 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

joel.larin — Wed, 25 Oct 2023 14:27:04 GMT

Revision 15 posted to Guide by joel.larin on 10/25/2023 2:27:04 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

joel.larin — Wed, 25 Oct 2023 14:25:16 GMT

Revision 14 posted to Guide by joel.larin on 10/25/2023 2:25:16 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

joel.larin — Wed, 25 Oct 2023 14:24:26 GMT

Revision 13 posted to Guide by joel.larin on 10/25/2023 2:24:26 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces, Task Display Names, Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers, Folders, Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

joel.larin — Wed, 25 Oct 2023 14:23:53 GMT

Revision 12 posted to Guide by joel.larin on 10/25/2023 2:23:53 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces,Task Display Names,Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers,Folders,Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

joel.larin — Wed, 25 Oct 2023 14:22:28 GMT

Revision 11 posted to Guide by joel.larin on 10/25/2023 2:22:28 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Making Applications Available in Multiple Languages

You may need to build an application that is going to be used by people in different languages. There are two levels of internationalization that need to be handled:

Platform level - these are all base-product words, for example, the names of the five tabs, numerical value and date formats.
Application level - these are all application-specific words, for example record names and field labels on an interface.

Platform Internationalization

The 5 tabs and any of the base-product words in the Tempo interface will be translated.
- Filters and actions in the News tab
- Out-of-the-box filters in the Tasks tab
- Summary, News and Related Actions tabs in Records
- Search filter on the Reports tab
- Filters in the Actions tab
The Appian Designer, Designer Interface, and Administration Console out-of-the-box words will also appear in the user’s selected language. Keep in mind that most proper nouns or common abbreviations (Tempo, Appian, LDAP) will not be translated.
All out-of-the-box notifications will be sent to users in their selected locale.
Date and number formatting will be changed to reflect the user's selected locale.

Application Internationalization

Any displayed words that are application-specific will need to be internationalized during application design. Depending on the object type the approaches to internationalization are different.

Object Type	Approach
Applications	For situations with a limited set of language options (maximum 3), we recommend using a single application with all 3 languages displayed in line for Actions (see detail under Actions).To display Application names within the Actions tab in different languages create a separate published application for each target language, for example Case Management (for English speakers), and Zarzadzanie Sprawami (for Polish). Additionally, you will have to create language specific groups and secure the applications, otherwise users will see all the published applications.
Groups	Group names cannot be internationalized.
Actions	For sites using three or less enabled languages, you can name your Action in-line with the names in different languages visible. For example New Contract \| Neu Vertrag \| Nowy Kontrakt
Interfaces,Task Display Names,Record Views	Utilize the Load Resource Bundle plugin to retrieve correct labels for the referenced keys. Use per language resource file to store key value pairs. When the user accesses the interface, all field labels, instructions, validation messages, etc. will be retrieved from the resource bundle based on logged in user’s locale. This approach can be used for all expressionable locations: record views, user filters, etc. Avoid using multiple language tabs in the Process Model for task display names, use the Resource Bundle plugin instead.
Record List View	Internationalized apps need to use an expression-backed record to load the bundle once and pass the bundle into an element of the record source CDT. In the record list view the bundle element of the source CDT can be referenced to internationalize labels and data in the list view.
Reference Data	Utilize a similar approach as described in Managing Reference Data. However, instead of storing reference data labels, save data keys that you can then use for translation in the database. The updated table structure needs to have a label defined for the same key for each language. Create a view for data retrieval and a non-nested CDT to write data. On interfaces, retrieve all reference data from the database in one read operation that you can then use to populate fields and selection lists.
Record Types	Record Types cannot be internationalized.Do not define separate record types for different languages, this will break any record links and make embedded interfaces much more difficult to integrate. Customer A is a Customer no matter the locale of the user viewing the record.For sites using three or fewer enabled languages, you can name your Records in-line with the names in different languages visible.
Record List View User Filters	Use Expression User Filters to retrieve filter names and values using the same approach as Interfaces.
Related Actions	Related action names can be set dynamically in the Process Model Display Name field using expressions. It is no longer necessary to configure the legacy internationalization tabs to ensure that related action names are internationalized.
Reports	For sites using three or less enabled languages, you can name your Reports in-line with the names in different languages visible. For example, "Agent Performance".
News Events	News Events will always retain the language they were posted in.
News Feeds	News Feed names cannot be internationalized.
Knowledge Centers,Folders,Documents	Collaboration object names cannot be internationalized.
Dynamic Document Generation	In a case where internationalized documents must be generated from a template, translated versions of the template document can be stored in a folder with a locale identifier as a suffix (Eg: _en_US,_ es_ES, etc.).The correct template can be chosen using the Content Expressions plugin. Call getdocumentsfromfolder() specifying the locale as the filename and the template folder as the root folder in order to return your desired document template in the desired language.
Email	Emails can be internationalized using the Content Expressions plugin, Text File Utilities plugin, and html templates in multiple languages (text files). The text file names should be suffixed with the locale identifier (Eg: _en_US,_ es_ES, etc.). Call readtextfromfile(), specifying the file returned by getdocumentsfromfolder() specifying the locale as the filename and the correct template folder as the root folder in order to return your desired email in the desired language.

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform

Frequently Reused Appian Components

Devon Lee — Wed, 22 Mar 2023 16:08:01 GMT

Revision 10 posted to Guide by Devon Lee on 3/22/2023 4:08:01 PM

Skills Covered

Skills Checklist:

Identify benefits to reusing Appian components and interfaces in development.
List three frequently reused Appian components.
Identify strategies to ensure proper handling of reusable components.

Queries

Interface Components

Business Rules

Validator rules (email, SLA, date, etc.)
Formatting (Dates, datetimes, SSN, etc.)

Interfaces

Section headers
Grids
Charts/Graphs

Steps to Create Reusable Section Header

Create interface object using stamps, icons, and multiple types of formatted rich text.
For each element that could be different from instance to the next (stamp, header value) replace the element’s value with a rule input.
In all interfaces that will use this section header, reference the object and enter the desired values for the parameterized elements in the rule inputs.

Steps to Create Reusable Email Validator

Create expression rule to check if myUsername@mydomain.com ends with ‘@mydomain.com’ and does not contain any special characters in the username.
Once the validation is accurate, remove any direct reference of myUsername@mydomain.com from the expression and replace it with a rule input named ri!email.
In all form objects that require this validation, simply reference the object and enter the desired value into the parameter input for ri!email.

AppMarket Applications

Internationalization

Business Processes

Authentication

SAML and LDAP configuration is located in the Admin Console underneath Authentication. For more detailed instructions, see Configuring Multi-Factor Authentication (MFA).

Tags: design-patterns, Platform