Application Designer

The application designer is an interactive tool that lets you create comprehensive business solutions to deploy for your enterprise. For more information about the application object itself, see Applications.

Refer to the annotated screenshot above when reading about each of the features listed below:

  1. Create Objects
  2. Add Existing Objects
  3. Patch Applications
  4. Trace Relationships for Impact Analysis
  5. Delete Objects
  6. Search Application Contents
  7. Filter Application Contents
  8. Actions
  9. Missing Precedents
  10. Security Summary

Create Objects

The New menu launches dialogs where designers can quickly create objects. Simpler objects can be fully configured when creating them here. For more complex objects like interfaces or record types, these dialogs allow you to enter one or two pieces of information and quickly create the object, and optionally open it in a new window to continue configuring it in the full designer.

This gives designers the flexibility to choose between a breadth-first approach, where they quickly create many objects before fleshing them out and possibly dividing that work among several designers, and a depth-first approach where each object is fully configured before moving on. Objects that are created using the breadth-first approach are not yet fully configured, so designers may see an error at runtime.

Any objects created here are added to your application and you see them immediately after creation. Since application contents show as a flat list, when you create a new object and a folder to put it in at the same time, they often show up next to each other in the contents list after creation. Creating an object by duplicating an existing object allows you to choose from objects anywhere in the system.

New objects (including new applications) created in Appian Designer have the following default security:

  • If the creating user is of type System Administrator, then they are not added to the object's role map. Otherwise, they are added to the role map with administrator permissions.
  • If the object type supports security inheritance, then the new object inherits security.

Design objects can be created by users of type System Administrator or users in the Designer role, with the following exceptions:

  • Data stores, groups, and record types can only be created by users of type System Administrator
  • To create process models, users must be of type System Administrator, or be in both the Designer role and the Process Model Creators group.

Add Existing Objects

There are three ways to associate existing objects with your application, all accessed through the Add Existing menu:

  • Application Contents: Select an application to have all objects associated with that application associated with this application. Since actions are not design objects, but configurations on an application, this does not associate the selected application's actions with this application. All application contents will be added, including those you do not have permission to see.
  • Folder Contents: Select a folder to have that folder and all of its contents associated with the application. This includes all objects who have the selected folder as an ancestor. This is the fastest way to get the entire contents of a folder into an application.
  • Existing Objects: Select one or more objects to associate with this application. Selecting a folder in this way does not associate its contents with the application.

In this dialog, there are pickers for record types, reports, and process models, which are usually top-level objects, i.e., they are not referenced by other objects. All other object types can be selected in the fourth picker, though if they are required in this application, they also show up as a missing precedent. Appian recommends that you select the top level objects in this dialog, and then check the box to use missing precedents to retrieve the relevant related objects.

Process models in your My Models folder in /designer will not appear when searching here. Neither will any documents or folders from the Personal and Teams section of the Documents tab in /designer.

Adding objects into this application does not move them out of their current application, since objects can be in multiple applications. Since the new objects may rely on objects not in your application, this dialog allows you to immediately invoke Missing Precedents after adding objects, to check if you are now missing any objects from your application.

Patch Applications

Designers create patches to deploy updates for existing applications. A patch is a collection of application objects, exported and imported from inside the application to modify it directly. Patches are used to enhance existing business solutions without creating new applications, and may include bug fixes, enhancements, or new application objects.

To create a patch:

  1. Check for missing precedents to make sure that all objects that may need to be in the patch have been added to your application.
  2. Select one or more application objects. Use the date filter in the left nav to show all the objects that have been changed since the last deployment.
  3. Click the Add to Patch button in the toolbar. The current number of objects in your patch is displayed in the button label. The patch contents are discarded when you navigate away before exporting the patch.
  4. You can add objects multiple times to continue adding to your patch as you work.
  5. When you are done adding objects, click the Export Patch button in the toolbar to review your patch. From here, you can remove objects and rename your patch package.
  6. Exporting a patch posts an entry to the News feed just as exporting an application does. Only the author and the entry participants can see the entry.
  7. On your target environment, navigate to the application you are patching and click the Import Patch button in the toolbar. Importing your patch package here adds the objects directly to this application.

Importing a patch using the Import Application option does not throw an error. The objects are added to the system, but are not added to any application. If this is done accidentally, re-import the patch inside the correct application.

Importing an application using the Import Patch option does not throw an error. The application is added to the system as normal, but all of its objects are also added to the application you patched. You can remove them by selecting the objects imported with the patch and using the Remove from App option in the toolbar.

Trace Relationships for Impact Analysis

To understand how a design object is related to other objects, select an object in the application contents view and select Dependents or Precedents in the toolbar options.

For details and screenshots on what shows up in the list of dependents and precedents, see: Trace Relationships for Impact Analysis

NOTE: Impact analysis is not available for the following design objects: portal pages and discussion forums. This means that they do not show up in the list of dependents and precedents, and you cannot view their relationships.

Delete Objects

Data types can be deleted in bulk, other objects must be deleted singly. Deleted objects are removed from the system and cannot be restored. Consider checking the dependents of an object before deleting it, to understand which other objects may be using it.

The Remove from App toolbar option allows you to take objects out of your application and does not delete the object.

Search Application Contents

The controls in the left nav control which application objects appear in the grid. Designers can search for objects by name, description, and UUID. Both the search and the filters are applied at the same time.

When searching by multiple terms, such as "add user", objects whose name or description contain all of the search terms are returned. When searching by UUID, only objects whose UUID exactly matches the search string are returned.

Filter Application Contents

In addition to searching for objects, designers can also filter by type and/or last modified date. Both the search and the filters are applied at the same time.

The date filters take the user's time zone into account, so users in different time zones may see different objects when filtering on the same dates.

Some less-common object types are combined into one type filter: Group Types can be found using the Group filter, and Communities and Knowledge Centers can be found using the Folder filter.

Newly created objects are added to the application immediately, but may not immediately be visible if the current filter settings would hide it.

Actions

Actions are a configuration on an application that expose process models in end user interfaces. For process models to appear to a user, the application must also be published and that user must have view access to the application.

When choosing a process model to make an action, you can choose any published model in the system. That model is added to your application.

Missing Precedents

A precedent is any object that an object relies on to function properly. For deployment to another environment to be successful, all precedents of application objects must either be exported with the application, or already be present on the target environment.

The missing precedents dialog allows you to scan the application for referenced objects that are used by the application, but not associated with the application. An initial scan is performed when the dialog is first opened. From the list of missing precedents, designers can add objects to the application, and run another scan. The Referenced By column in the grid displays the object or objects that require each of the missing precedents, so that designers can tell why the missing precedent appears on the list.

Not all missing precedents need to be added to the application. Objects in related applications are deployed with those applications, and do not need to be added even though they are precedents of objects in this application. To narrow the list to only precedents that need to be added, use the filter options below the grid:

  1. Below the grid, click the link. If none of the missing precedents in the list are in any other application, the link does not appear, because there is nothing to filter by.
  2. A list of applications displays. These are all the applications that one or more of the missing precedents belong to.
  3. Check the box for an application to hide all missing precedents associated with that application.
  4. Click the Save current filter selection link to save the current filters to the application. Any designer viewing the application sees the same filters, and they are exported and imported with the application. Application filters saved here never cause export or import errors.

Only save a filter option when the corresponding application will be kept up to date in all environments. For example, any missing precedents from your Common Objects Application should not be added to this application, as the Common Objects Application is intended as a library that other applications can use. Saving that application as a missing precedents filter ensures that you do not accidentally add its objects to your applications.

Selecting all the applications in the list shows only missing precedents that are in no applications. These should always be added to your application, or moved to another application. Setting up these filters correctly allows a designer to confidently add all remaining missing precedents to the application.

Exceptions

The following items are not identified as missing precedents during a scan of your application. Make sure to add these manually.

Security Summary

The security summary shows a single list of all the objects in your application grouped according to their security. Objects with the same users and groups at the same permission levels are shown together. You can edit the security of any section of objects in bulk.

Uses

The security summary allows you to review security across all the objects in your application without having to individually view each object. It also allows you to edit the security of sections of objects. Here are a few examples of when you might use it:

  • If you create a prototype application first and then configure security as part of a later iteration, use the security summary to make sure you haven't forgotten any objects and correct any omissions.
  • If you have two process models in your application that are both used by the same set of users, use the security summary to confirm they have the same security configuration.
  • It is a best practice to avoid securing objects to users, but sometimes it is helpful to do so temporarily. The security summary allows you to quickly scan the list of distinct security configurations and make sure these temporarily added users haven't been mistakenly left in place after the need is over.
  • Often, all the expression rules and interfaces in an application should have the same security. The security summary makes it easy to discover unintentionally disparate role maps and correct them.

Grouping

Objects are shown together if all of the following are true:

  • They are directly configured with the same users and groups at the same permission levels.
  • They are inheriting the same users and groups at the same permission levels.
  • Their default access levels are the same.

Permission levels with no configured user or group are ignored, so for example, although only process models have the process initiator and process manager permission levels, if these are empty they can still potentially be shown with other kinds of objects.

Inherited users and groups are considered distinct from directly configured users and groups. This means that if you have twenty expression rules all inheriting their security from a rule folder, the rules will be shown together and the rule folder will be shown separately. This distinction allows you to easily identify the object that is the source of inherited users and groups.

Note: Although the security summary shows disparate design objects together when they have the same users and groups in the same permission levels, remember that these levels can mean different things for different design objects. For example, to run a web API a user must have viewer access or be a member of a group with viewer access, but anyone can evaluate any expression rule if it's invoked by an interface or process model they are using.

Making Changes

If you see something that should be changed while viewing the security summary, you can click the Edit Security button in the top of that section. This opens a dialog with a single editable role map for all the objects in that section. The role map configured here will be applied to all the listed objects, overwriting any existing security settings.

NOTE: When the configured security cannot be applied to all listed objects, any roles that do not apply to all objects will only be saved to applicable objects. In the screenshot below, PR Users will only be added to the role maps of process models in that section of the security summary. If that group previously had Viewer access, the group will now have Initiator access on all process models and no access for all other objects.

FEEDBACK