LiveCycle configuration parameters – Part 1

What is a configuration parameter?

LiveCycle configuration parameters are one of the most useful and overlooked tools in the Enterprise LiveCycle developer’s toolbox. Simply put, they allow you to edit application variables from the Administration interface (AdminUI) to directly apply to the application you have developed and deployed to the LiveCycle server. This allows you to easily make changes to the application after deployment without having to change, re-deploy and test the application.

Configuration parameters (Adobe Docs)

Why would I use one?

1. Best Practices

As a developer, it is always good practice to make your applications as highly portable and uncoupled from the environment as possible which, in practice, means never hard-coding properties like directories, usernames, passwords, URI’s, etc. that your application may use during run-time. There are limitations in every environment that make this unavoidable in practice (LiveCycle is no exception here) but as a general rule, you should never hard-code any configuration or environment properties in your application.

2. Change Control

In an environment that has a very tight change control process in place this can be invaluable. Raising a change request for an application configuration change is always an easier prospect than one requiring a new build version.

When should I use a configuration parameter?

Configuration parameters should always be used where something could possibly change in the environment that you have deployed your application into.

Some examples:

  • Directories – Document Output, Input, Logs, Failures, Watched Folders, etc. Anything in your process or linked DSC that refers to a local or UNC directory should always be set as a configuration parameter.
  • Usernames and Passwords – Any secure environment should change important passwords regularly. Consequently, these should never be hard-coded in any application.
  • External URI’s, Web Service endpoints, etc. – Any external calls that are not internal to the application should be a configuration parameter.

How do I implement a configuration parameter?

During development you can elect to make any variable a configuration parameter simply by selecting the Configuration parameter radio button when you create a new variable in Workbench:

Example Configuration Variable

Example Configuration Parameter

When you select the Configuration parameter radio button, you will notice a few things happen. Enduser UI Items section disappears, meaning you can no longer search or interact with the variable in Livecycle Workspace. Also, and more importantly, your available variable Type list becomes smaller. The only types available for a configuration parameter are:

  • Boolean
  • Integer
  • Short
  • String
  • Long

Setting a Default Value is highly recommended during development so you don’t need to constantly open AdminUI and set the parameter properties after you deploy the application.

Likewise, it is recommended to set a descriptive Title parameter as this is the text that will appear in the AdminUI page. If you don’t use a Title the Name of your variable will appear (strOuputDirectory in this case). As a competent developer you are already supplying adequate variable Titles and Descriptions in all of you applications anyway …right?

Once you have created the configuration parameter, you use it as you would any other variable you create in your processes. Updating the variable during the process does not change the default setting in the application.

For example:

Using the Configuration Parameter

Using the Configuration Parameter

To modify the Configuration parameter once you have deployed the application is easy. Just log in to the LiveCycle AdminUI and browse to the Application and the Process you created the variable in:

Changing configuration parameters in AdminUI

Changing configuration parameters in AdminUI

Now whenever you update the configuration parameter via the AdminUI, your application will automatically use the new value for strOutputDirectory and change the location of where your PDF’s are saved. All without opening the application, finding where the path is used, modifying all instances of the path, redeploying and testing.

Stay tuned for Part 2 – I will describe a practical way to organise your configuration parameters within an application you might create in the enterprise.


Everything AEM aka CQ5 based on my experience listed here.

Adobe AEM The Right Way

Best practices, tips, and tricks for your Adobe AEM project


A WCM journey with Day/Adobe CQ

Technoracle (a.k.a. "Duane's World")

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Adobe LiveCycle Blog

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.


A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Code Monkey

Ramblings of a Developer