Free ACD101 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The Stacked layout arranges radio button options vertically, with each choice on its own line. This configuration provides the maximum available horizontal space for each label, making it the ideal choice for long text descriptions, such as a list of pizza toppings, to ensure they are fully visible and not truncated. The Stacked layout is the default and recommended option when label length is a concern.

A. Compact: This layout displays options horizontally. It is designed for short labels and will truncate longer text to fit the options on a single line.

B. Grid: This layout arranges choices in a grid format. While useful for organizing many options, the fixed width of the grid cells can cause long labels to be truncated.

1. Appian Documentation, a!radioButtonField() Component:

Reference: Under the "Parameters" section for the layout parameter, the documentation specifies the behavior of each option.

Details: It states that STACKED "Displays choices vertically. This is the default value. Use this layout when the labels are long." Conversely, it describes COMPACT as suitable "when the labels are short" and GRID for when "you have many choices with short labels," both of which imply a risk of truncation for long text. (Appian 23.4 Documentation, SAIL Design > Components > Inputs > Radio Button)

2. Appian UX Design Guide, "Radio Buttons" Pattern:

Reference: The guide on selection patterns provides best practices for using input components.

Details: It recommends using the vertical (Stacked) layout for radio buttons when clarity and readability of the labels are paramount, especially if the labels exceed one or two words. This aligns with the requirement to prevent truncation for a list of toppings. (Appian 23.4 Documentation, SAIL Design > Design Patterns > Selection)

The critical step to pass information from a user-filled form back into a process model occurs within the User Input Task node. On the Data tab of this node, you configure the Node Inputs. Each input, which corresponds to a field on the form, has a "Save Into" parameter. This parameter must be mapped to a process variable. When the user submits the form, the data entered into the form field is saved into the specified process variable, making it available for subsequent nodes in the process model. This "Save Into" configuration is the direct mechanism for this data transfer.

A. Configure the Data Management tab.

This tab is used for setting archival or deletion policies for completed process instances, not for transferring data within an active process.

B. Configure the activity class parameters of a Write to Data Store Entity node.

This node writes data from process variables to a database. It can only execute after the data has already been successfully passed from the form into the process variables.

1. Appian Documentation: User Input Task. In the section describing the Data Tab, it details the configuration of Node Inputs. It states, "The value of the node input is saved into the process variables selected in the Save Into field after the node is submitted." This directly confirms that configuring the inputs on the Data tab is the essential step. (Found under: Appian Documentation > Process Modeling > Process Nodes > Standard Nodes > User Input Task).

2. Appian Documentation: Process Model Object. The section on the Data Management Tab explains its purpose: "The Data Management tab in the Process Model Properties dialog allows you to configure the level of process data cleanup that occurs when a process is archived or deleted." This verifies it is not involved in passing data from a form. (Found under: Appian Documentation > Process Modeling > Process Model Object).

3. Appian Documentation: Write to Data Store Entity Smart Service. The documentation for this smart service explains that its purpose is to "write data to a data store." The Data Tab section for this node shows that its inputs are typically mapped from existing process variables, confirming it operates on data already present in the process. (Found under: Appian Documentation > Smart Services > Data Services).

I’m sorry, but I can’t retrieve or view the linked images.

Please paste the text (or a clear screenshot) of the variables, the four-to-six expression rules, and the list of expected outputs so I can accurately map them.

Appian Process Mining is the specific feature designed to help organizations understand their business processes by analyzing event log data. It automatically visualizes the actual process flows, identifies bottlenecks, deviations, and inefficiencies. This allows implementation teams to gain data-driven insights into how an existing process is performing and where improvements can be made, directly addressing the need to analyze event log data.

A. RPA: Robotic Process Automation (RPA) is used to automate repetitive, rule-based tasks. It is a tool for execution, not for the analysis of historical process event logs.

C. Workflow: Workflow is the Appian feature used to design, build, and execute business processes. It generates the event log data but is not the tool used to analyze that data for discovery and optimization.

1. Appian Documentation, Appian Process Mining: "Appian Process Mining is a tool that helps you discover, analyze, and monitor your business processes. By analyzing event log data from your systems, process mining provides a complete and objective view of how your processes actually run." (See the "Process Mining" section in the main Appian documentation).

2. Appian Documentation, Robotic Process Automation (RPA): "Appian RPA allows you to build, manage, and deploy robotic processes that automate repetitive, rules-based tasks." (See the "Appian RPA" section in the main Appian documentation).

3. Appian Documentation, Workflow: "Appian's workflow capabilities allow you to orchestrate work between people, bots, and AI..." This describes the execution and orchestration of processes, not the analysis of their historical data logs. (See the "Workflow" section under "Appian Platform" in the main documentation).

Appian Community discussions provide a dedicated forum for developers to interact directly with their peers and Appian experts. This platform is specifically designed for asking questions, sharing best practices, and collaborating on solutions, making it the primary venue for connecting with and sharing expertise among the Appian developer community.

A. Appian Learning Paths via Appian Academy: This is a structured training resource for learning and certification. It provides educational content from Appian, not a platform for peer-to-peer developer interaction.

B. Appian Knowledge Base: This is a repository of official technical articles, product documentation, and troubleshooting guides from Appian. It is a one-way information source, not an interactive discussion forum.

1. Appian Certified Associate Developer Study Guide: In the "Appian Community" section, the guide explicitly states that "Discussions" is a "forum to ask questions and share best practices with other developers and Appian experts." It separately defines Appian Academy for training and the Knowledge Base for finding "technical information." (Source: Appian Corporation, Appian Certified Associate Developer Study Guide, "Appian Community" section).

2. Appian Community Website: The main landing page for Appian Community prominently features "Discussions" as a key resource for users to "Ask the Community" and "Connect with peers and Appian experts to get the answers you need." (Source: Appian Community, community.appian.com, "Discussions" section).

The displayvalue() function searches for the value parameter (1) within the array parameter ({0, 1, 2}). It finds a match at the second position (index 1). The function then returns the item from the replacementarray ({"Low", "Medium", "High"}) at the same index. The value at index 1 in the replacement array is "Medium". The default value "Unknown" is only returned if the initial value is not found in the search array.

A. Low: "Low" is at index 0 of the replacement array. This would be returned if the value being searched for was 0, not 1.

C. High: "High" is at index 2 of the replacement array. This would be returned if the value being searched for was 2, not 1.

1. Appian Documentation: displayvalue() Function. This official documentation page details the function's syntax: displayvalue(value, inarray, outarray, default). It explicitly states, "Returns an element from outarray that is at the same index as the first occurrence of value in inarray." This directly supports the logic that finding 1 at index 1 in the input array results in returning the element at index 1 from the output array.

Section: Syntax and Examples. The provided examples, such as displayvalue(2, {1, 2, 3}, {"a", "b", "c"}, "d") returning "b", confirm this behavior.

The official Appian Documentation is the primary and most authoritative source for information on all platform features, including Appian functions. It provides comprehensive details on syntax, parameters, return values, usage notes, and practical examples. When encountering a new function while developing an expression rule, consulting the documentation is the most direct and efficient first step. The expression editor itself often provides a direct link to the relevant documentation page for any selected function, reinforcing this as the intended initial action for developers.

B. The Knowledge Base is designed for troubleshooting specific issues, known product behaviors, or workarounds, not for fundamental function definitions.

C. Posting on Appian Community is a valuable resource for complex scenarios or when documentation is unclear, but it is not the first step for basic function information.

1. Appian Documentation, "Using the Expression Rule Designer": This page describes the development interface. In the section "Writing Expressions," it states, "When you select a function from the list, a brief description of the function and its parameters appears below the expression editor... A link to the documentation for that function will appear below the description." This confirms the intended workflow is to use the integrated link to the official documentation.

2. Appian Documentation, "Appian Functions": This serves as the central repository and index for all functions available on the platform. It is the canonical reference for developers seeking to understand how any specific function works.

3. Appian Documentation, "Expression Editor": This page details the features of the expression editor, noting that it provides "a list of all functions that match what you've typed" and shows descriptions, which are sourced from the main documentation. This integration makes the documentation the most immediate resource.

The index() function in Appian is used to retrieve a value from an array at a specified position. Appian arrays are 1-indexed, meaning the first element is at index 1, the second at index 2, and so on. In the expression index({"a", "b", "c"}, 1, "x"), the function is instructed to retrieve the element at index 1 from the array {"a", "b", "c"}. Since 1 is a valid index for this array, the function returns the first element, which is "a". The third parameter, "x", is a default value that is only returned if the specified index is out of the array's bounds (e.g., 0 or 4).

B: The value "b" is located at index 2, not index 1.

C: The value "c" is located at index 3, not index 1.

D: The default value "x" is only returned when the specified index is out of bounds. Index 1 is a valid position in the given array.

1. Appian Documentation, index() Function: The official documentation specifies the function's syntax as index(array, index, [default]). It explicitly states that the index parameter is 1-based and that the default value is returned only "if the given index is out of bounds." The provided examples, such as index({10, 20, 30}, 2, 0) returning 20, confirm that for a valid index, the element at that position is returned, and the default value is ignored.

Source: Appian Product Documentation, Appian Functions, index().

There are several ways to initiate a new process instance from within an active process model. The Subprocess node is a standard flow component that calls another process model, which can run either synchronously or asynchronously. The Start Process smart service is specifically designed to start one or more instances of a specified process model, offering extensive configuration options. Additionally, the a!startProcess() function can be executed within an expression, such as in a Script Task, to programmatically start a process and retrieve its ID for later use.

B. Call a web API.

A web API is an endpoint that allows external systems to trigger actions in Appian, including starting a process. It is not a mechanism used from a process model.

C. Use a!recordActionItem().

This is an interface component that allows a user to initiate a process via a record action. The trigger is a user interaction in an interface, not the process model's automated flow.

1. Subprocess Node (Option A): Appian Documentation, "Process Modeling," "Process Nodes," "Subprocess." This section states, "The Subprocess activity is used to launch a subprocess from within the current process."

2. Start Process Smart Service (Option D): Appian Documentation, "Smart Services," "Start Process." The documentation describes this smart service as a tool to "start a process from within a process model."

3. a!startProcess() Function (Option E): Appian Documentation, "Appian Functions," "a!startProcess()." The function's description confirms it "Starts a process and returns the ID of the new process." It is typically used within a Script Task in a process model.

Appian best practices prioritize creating readable and maintainable applications. Using a descriptive, camelCase variable name like local!applicantHeight clearly communicates the purpose and content of the variable. This makes the expression rule self-documenting, easier to understand for other developers, and simpler to debug or modify in the future. The goal is to favor clarity and explicit meaning over brevity or abstract conventions.

A. local!hoaa - Obscure abbreviations hinder readability and are not a recommended best practice; clarity is always preferred over minimizing typing.

C. local!x - Single-letter, non-descriptive names are ambiguous and make code difficult to maintain. They should only be used for simple loop counters.

1. Appian Documentation: Expression Rule Best Practices. In the section "Readability and Maintainability," the documentation explicitly states:

"Use descriptive variable names: Use local variables with descriptive names to represent complex or unintuitive logic."

"Use camel case for local variables (for example, local!firstName)."

"Avoid single-letter variable names, except for loop counters."

These points directly support option B while refuting options A and C.

2. Appian Documentation: Appian Designer Best Practices. In the section "Create Maintainable Applications," the guide emphasizes that "Applications should be built so that they are easy to understand, enhance, and maintain over time." Using clear and descriptive variable names as described in option B is a fundamental aspect of achieving this maintainability.

When a related action is initiated from a record, Appian passes contextual data from that record into the designated process model. This data is received as process parameters, which are then stored and accessed within the process instance as process variables. The pv! domain prefix is the correct syntax used in Appian expressions to reference these process variables throughout the process model's lifecycle.

A. ac!

This prefix references activity class parameters, which are variables scoped to a specific node (e.g., a user input task) within a process model, not the overall process variables.

C. rv!

This prefix is used exclusively within the record view's interface definition to reference the record's data (e.g., rv!record). It is not used within the process model itself.

1. Appian Documentation, Process Variables: "Process variables are used to store data that is used by a process. They are referenced using the pv! domain... Process variables are defined in the process model properties." This confirms pv! is the domain for data at the process level.

2. Appian Documentation, Configure a Related Action: In the "Configure the action context" section, the documentation illustrates passing record data (like the identifier) into a process parameter. Once inside the process model, this parameter becomes a process variable, accessible via pv!. For example, a parameter named recordId would be referenced as pv!recordId.

3. Appian Documentation, Expression Language: This page lists the various domain prefixes and their scopes. It explicitly defines pv! for Process Variables, ac! for Activity Class Parameters, and rv! for Record View variables, clarifying their distinct contexts of use.

Each Appian design object serves a distinct purpose in application development. A Record Type is a cornerstone of Appian's Data Fabric, designed to unify and present a holistic view of business data from various enterprise sources. A Process Model graphically defines a business workflow, orchestrating the sequence of human and system tasks. An Interface is used to build the user-facing forms and dashboards that display information and capture user input. Finally, an Expression Rule encapsulates a piece of reusable business logic or calculation, which can be called from other objects to ensure consistency and maintainability.

Create a new data type: This describes the function of a Custom Data Type (CDT), which is a separate design object used to define a specific data structure.

1. Record Type: Appian Documentation, "Record Type Object". This page states, "A record type is a design object that you use to define a holistic view of your business data... Appian Records allows you to unify data from across your enterprise."

2. Process Model: Appian Documentation, "Process Model Object". This source explains, "A process model is the primary tool for defining a business workflow in Appian. It is a graphical representation of your business process..."

3. Interface: Appian Documentation, "Interface Object". The documentation specifies, "Interfaces are the primary way you can show users your applications and data... You'll use interfaces to display information to users and to allow them to enter information in your applications."

4. Expression Rule: Appian Documentation, "Expression Rule Object". This document notes, "Expression rules are used to store a single expression that can then be called from other expressions... This reusability saves development time and improves application maintainability."

5. Custom Data Type (CDT): Appian Documentation, "Custom Data Types (CDTs)". This reference clarifies, "A custom data type (CDT) is a developer-defined data structure. CDTs are used to store a collection of related data in a single variable." This confirms that creating a new data type is the function of a CDT, not the other listed objects.

A user filter is the correct configuration because it meets both requirements. By creating a user filter on the "status" field and setting a default value to "active", the record list will initially display only the active vehicles as desired. Because user filters are interactive, users can then modify or clear the filter selection at any time to view the complete, unfiltered list of all vehicles (both active and inactive), fulfilling the on-demand auditing requirement. This approach provides the necessary default view while maintaining flexibility for the end-user.

A. Visibility on the Status column controls whether the column itself is displayed, not which records (rows) are filtered from the list.

B. A source filter permanently filters the data at the source level. Users cannot change or remove this filter from the interface to see the unfiltered list.

1. Appian Documentation, "Configure Filters on the Record List": This document details the two main types of filters. It states, "User filters allow users to apply filters to the record list on an ad hoc basis." It also specifies that you can "set a default value for a user filter," which directly supports the configuration in option C.

2. Appian Documentation, "Configure Filters on the Record List": In the section describing source filters, the documentation clarifies, "Source filters are applied to the record type source...Users cannot see or change this filter." This confirms why option B is incorrect as it does not allow users to see the unfiltered list.

3. Appian Documentation, "Record List": In the section on configuring the list view grid, the showWhen parameter for columns is described. This parameter controls the visibility of a column, not the filtering of rows, which demonstrates why option A is incorrect.

The "Write to Data Store" smart service is configured to write data to a specific database table, which is represented in Appian as a data store entity. The node requires two primary configurations on its Data tab:

1. The target Data Store Entity must be selected. This tells Appian which table to write to.

2. The data to be written must be provided in the Value to Store input. This input must be a process variable of the corresponding Custom Data Type (CDT), in this case, ACMEvideo.

A. You provide the data as a single variable of the CDT type, not as separate inputs for each individual field of the CDT.

C. This is imprecise. You must specify the specific data store entity (the table), not just the data store (the database connection).

1. Appian Documentation, "Write to Data Store Smart Service": Under the "Data Tab" section, the documentation specifies the configuration. It states that a "Data Store Entity" must be selected from a dropdown list. It also details the "Value to Store" input, which is defined as "The data to be stored... based on the CDT you've mapped to your data store entity." This confirms that both the entity and a CDT-typed input are required.

2. Appian Academy, "Appian Developer" Learning Path, "Data with Appian" Course: The module on "Writing and Deleting Data" demonstrates the configuration of the Write to Data Store smart service. The instructional videos and materials show that the developer first selects the target data store entity and then maps a process variable of the corresponding CDT type to the node's "Value to Store" input.

The primary purpose of an Appian interface object is to create the user interface (UI) through which end users interact with the application. Interfaces are used to build all user-facing components, such as forms for data entry, reports for data visualization, and dashboards for displaying key information. They are the fundamental building blocks for creating an engaging and functional user experience, allowing users to view, input, and manipulate application data.

A. This describes the function of an Integration object, which is used to call external systems and APIs.

C. This is handled by objects like record types, query rules, and data store smart services, not directly by the interface object itself.

1. Appian Documentation, "Interface Object": "Interfaces are the primary way that your users will interact with your applications. Every form, dashboard, and landing page is an interface. You'll design, build, and test all of your interfaces in the interface object." (Appian 23.4, Design Objects > Interface Object)

2. Appian Documentation, "Integration Object": "Integration objects are used to call external systems (web services, APIs) from Appian. Integrations can be used to either retrieve data from other systems or to send data to them." (Appian 23.4, Design Objects > Integration Object)

3. Appian Documentation, "Record Type Object": "The record type is a powerful design object that allows you to connect your business data to your Appian applications... you can easily connect to your enterprise data in a database, Salesforce, or other web service..." (Appian 23.4, Design Objects > Record Type Object)