View Full Appian ACD201 Exam Dumps and Practice Test Dumps.

Question 261. When should an Appian editable grid generally be used instead of a read-only grid?

1. When users only need to search thousands of records
2. When the grid must display only process-report data
3. When users need only to view and sort information
4. When users need to modify multiple rows of data directly within a tabular interface

Correct Answer: 4. When users need to modify multiple rows of data directly within a tabular interface

Explanation:

The editable grid, configured with a!gridLayout(), is designed for scenarios where users need to work with editable interface components directly inside rows. For example, an order-entry form may allow users to modify quantity, price, or description values for several line items without opening a separate form for every item. If information is purely for viewing, searching, filtering, sorting, or paging, Appian recommends using a read-only grid instead. Choosing the correct grid type is important because editable grids can contain many interactive components, and excessive numbers of editable cells can increase interface evaluation time and affect performance.

Question 262. A developer needs users to page through 5,000 rows while editing individual records. What is the BEST design?

1. Use a read-only grid with paging and provide an edit link or record action for each row
2. Load all 5,000 rows into one editable grid
3. Use an editable grid and enable its paging parameter
4. Store all rows in one text field

Correct Answer: 1. Use a read-only grid with paging and provide an edit link or record action for each row

Explanation:

Paging is not supported by Appian editable grids. Loading thousands of editable rows would also create a very large number of interface components and could result in poor performance. When users must browse a large dataset and edit selected entries, Appian recommends using a read-only grid that supports paging and then providing a link or record action for editing an individual row. This design keeps the primary grid efficient while still providing the required editing capability. Editable grids are better suited to relatively manageable collections where inline editing is an important part of the user experience.

Question 263. What is the PRIMARY accessibility purpose of configuring rowHeader on an editable grid?

1. To make the first column bold
2. To freeze the selected column while scrolling
3. To identify a column whose value screen readers announce as context when navigating cells in that row
4. To prevent users from reordering the row

Correct Answer: 3. To identify a column whose value screen readers announce as context when navigating cells in that row

Explanation:

The rowHeader parameter identifies which column should act as the contextual header for each row. This setting does not create a visible formatting change. Instead, it improves accessibility by allowing screen readers to announce the row-header value as users navigate through other cells in the same row. Appian recommends configuring a row header for grids, and the first meaningful text column is often an appropriate choice. Accessibility settings should be treated as part of interface design rather than an optional visual enhancement because they help users who rely on assistive technology understand the relationships between grid values.

Question 264. Which capability is provided by the Appian read-only grid but is not supported as paging in an editable grid?

1. Displaying text
2. Paging through a larger dataset
3. Showing a component label
4. Displaying data in rows and columns

Correct Answer: 2. Paging through a larger dataset

Explanation:

Appian’s read-only grid is designed for browsing datasets and supports capabilities including searching, filtering, selecting, sorting, and paging. The editable grid, by contrast, focuses on inline editing and does not support paging. This distinction matters when choosing a component for high-volume data. A read-only grid can retrieve and display manageable pages of information while users navigate a much larger result set. Attempting to reproduce the same behavior by loading every record into an editable grid can lead to excessive component counts and slower interface evaluations. Component selection should therefore reflect both the interaction requirement and expected data volume.

Question 265. Why is a record type often a strong data source choice for a read-only grid?

1. The grid can take advantage of record-based search and user filters already defined for the record type
2. Record types disable sorting to improve performance
3. Record types automatically make all data editable
4. Record types eliminate the need for data security

Correct Answer: 1. The grid can take advantage of record-based search and user filters already defined for the record type

Explanation:

Using a record type as the data source for a read-only grid lets developers take advantage of Appian’s record-centric capabilities. The grid can benefit from search and user filters already configured on the record type instead of requiring developers to reproduce equivalent functionality manually in every interface. This promotes reuse and consistency across applications. Record types also integrate naturally with related data and record security. Using a record type does not make data automatically editable or remove authorization requirements. Appian’s grid design guidance recommends helping users locate information through logical sorting, commonly used filters, and appropriate search functionality.

Question 266. A field must allow the user to select one value from several thousand possible choices. Which component is generally more appropriate than loading all choices into a dropdown?

1. Boolean checkbox
2. Rich text display
3. Progress bar
4. Picker component

Correct Answer: 4. Picker component

Explanation:

Dropdowns work best when the number of options is relatively small. If there are thousands of possible values, loading all options into the dropdown can create unnecessary interface work and make selection cumbersome. Appian recommends considering a picker for large option sets. A picker can retrieve suggestions as the user searches, allowing the performance cost to occur as needed rather than requiring every possible option to be loaded initially. This pattern is particularly useful for selecting customers, employees, products, locations, or other high-cardinality entities. Component choice should balance usability with the amount of data the interface must evaluate and display.

Question 267. A form requires the user to indicate whether they agree to a policy using a single true-or-false choice. Which component is BEST suited to this requirement?

1. Multiple dropdown
2. Boolean checkbox
3. Standard checkbox list containing several options
4. Record picker

Correct Answer: 2. Boolean checkbox

Explanation:

A boolean checkbox is designed for a single true-or-false decision, such as agreeing to terms, confirming a statement, or toggling a simple setting. A standard checkbox component is more appropriate when users may select none, one, or several items from a set of choices. Similarly, radio buttons or dropdowns are normally used for mutually exclusive choices with multiple possible values. Choosing the component whose behavior naturally represents the data makes interfaces easier to understand and reduces unnecessary configuration. Appian’s selection guidance specifically distinguishes a boolean checkbox from a standard multi-option checkbox component for this reason.

Question 268. Which configuration would be invalid for the choiceValues parameter of an Appian dropdown?

1. A list of unique numeric identifiers
2. A list of unique text codes
3. A list containing null or duplicate values
4. A record field containing unique IDs

Correct Answer: 3. A list containing null or duplicate values

Explanation:

The values supplied to a dropdown’s choiceValues parameter must correspond to the displayed labels and must not contain null or duplicate values. Appian needs each selectable choice to map predictably to a valid saved value. Duplicates would make different displayed options indistinguishable after selection, while null values do not provide an appropriate selectable value. The visible labels and saved values can differ—for example, a user might see employee names while employee identifiers are saved. Separating user-friendly labels from stable underlying identifiers is a common pattern that makes forms understandable while preserving clean application data.

Question 269. What must a custom picker’s suggestFunction return?

1. A ProcessModel
2. A Document
3. A Boolean value
4. A DataSubset containing display data and corresponding identifiers

Correct Answer: 4. A DataSubset containing display data and corresponding identifiers

Explanation:

A custom picker uses its suggestion function to determine which options should appear as the user enters search text. The referenced function or rule takes a Text search value and must return a DataSubset. Within that DataSubset, the data contains the labels that users see, while the identifiers contain the values that are saved when a suggestion is selected. This separation lets developers build search experiences around virtually any suitable application data source. Developers can also configure maximum selections and provide labels for already-selected values. The custom picker is particularly useful when standard record-picker behavior does not fit the application’s requirements.

Question 270. What happens to a component when its showWhen parameter evaluates to false?

1. It remains visible but becomes disabled
2. It is hidden and is not evaluated
3. It is automatically removed from the interface definition permanently
4. It becomes visible only to administrators

Correct Answer: 2. It is hidden and is not evaluated

Explanation:

The showWhen parameter controls conditional display of many Appian interface components. When it evaluates to false, the component is hidden and Appian does not evaluate that component. This can be useful not only for creating dynamic interfaces but also for avoiding unnecessary work associated with content that users do not currently need. Developers should distinguish showWhen from disabled. A disabled component remains visible and communicates that the field exists but cannot currently be changed, while a hidden component is not presented at all. Choosing between those behaviors should reflect the intended user experience and business requirement.

Question 271. A File Upload component is used on a regular interface that is not a process start form or task. What should be used to submit the uploaded files?

1. a!submitUploadedFiles() in the saveInto of an appropriate submit button or link
2. a!queryRecordType()
3. a!refreshVariable() only
4. a!startProcessLink() exclusively

Correct Answer: 1. a!submitUploadedFiles() in the saveInto of an appropriate submit button or link

Explanation:

File uploads behave differently depending on where the interface is used. On process start forms and User Input Tasks, submission participates naturally in the process-form lifecycle. When a File Upload component is used outside those contexts, Appian provides a!submitUploadedFiles() so the temporary uploaded files can be submitted explicitly from a button or link’s saveInto. This distinction is important because selecting a file in the browser does not by itself mean the document has completed its intended Appian submission lifecycle. Developers should design the surrounding action and persistence behavior so users clearly understand when their uploaded documents are actually committed.

Question 272. Where can administrators control which file extensions are permitted for the Appian File Upload component?

1. In each process model’s security settings
2. In the application’s site navigation
3. In File Upload settings in the Admin Console
4. Only in the user’s browser configuration

Correct Answer: 3. In File Upload settings in the Admin Console

Explanation:

Appian provides centralized File Upload settings in the Admin Console where administrators can control permitted file extensions. Central configuration helps organizations apply consistent restrictions instead of relying entirely on individual interfaces to enforce file-type policy. Application-level validations may still be useful when a specific feature accepts a narrower subset of files, but platform-wide restrictions provide an important baseline. File-type controls should be combined with appropriate document security, validation, and organizational policies. Developers should not assume that changing a browser setting or process-model security determines which extensions the Appian platform accepts for uploads.

Question 273. When a File Upload component is used with a document management record type, what can be supplied as its target?

1. Only a process-model UUID
2. The document management record type
3. A site page name
4. A security-group description

Correct Answer: 2. The document management record type

Explanation:

For record-type-based document management, Appian allows the File Upload component’s target to reference the configured document management record type. The component’s value and saveInto can then use the document field on that record type. This approach allows document creation to participate in Appian’s modern record-based document-management architecture rather than requiring developers to manually manage every destination folder. The pattern can be used in a start-form workflow where the interface captures the document record data and passes it into a process. Appropriate record and record-level security should still be configured to ensure users can access only authorized documents.

Question 274. A form needs users to upload several documents in one File Upload component. Which statement is correct?

1. Appian requires a separate process model for every file
2. The component can upload only one document under all circumstances
3. Multiple uploads are available only through a plug-in
4. The File Upload component supports multiple file selection directly

Correct Answer: 4. The File Upload component supports multiple file selection directly

Explanation:

Appian’s File Upload component supports uploading one or more files directly, so developers do not need to create a separate file-upload field for every possible document. The maxSelections parameter can be used to control how many files users are allowed to select when the business requirement imposes a limit. Multiple-file support is useful for scenarios such as attaching supporting evidence to a case or adding several documents to a request. Developers should still validate document requirements, destination configuration, and security. Simplifying the interface with one multi-file component generally produces a cleaner experience than dynamically generating many separate upload controls.

Question 275. According to Appian chart design guidance, when is a pie chart MOST appropriate?

1. Showing parts of a whole using a small number of distinct categories
2. Displaying hundreds of sequential time intervals
3. Comparing large amounts of positive and negative data
4. Showing the relationship between two continuous numerical measures

Correct Answer: 1. Showing parts of a whole using a small number of distinct categories

Explanation:

Pie charts are intended to communicate how individual categories contribute to a whole. Appian recommends using them only when values fall into clear, distinct categories and advises limiting a pie chart to no more than five slices. Data and category labels should be included so users can interpret the visualization without relying entirely on visual comparison. Pie charts are not ideal for time-series trends, large numbers of categories, or data containing negative values. Selecting a chart should begin with the question the user needs the visualization to answer rather than forcing available data into a preferred chart style.

Question 276. A dataset contains both positive and negative financial variances. Which visualization is preferable to a pie chart?

1. A pie chart with negative slices
2. A donut chart with negative slices
3. A bar or column chart that clearly represents values above and below zero
4. A record picker

Correct Answer: 3. A bar or column chart that clearly represents values above and below zero

Explanation:

Negative values are problematic in pie charts because pie slices visually represent proportions of a whole. Although a negative value can technically appear as a slice, its graphical area does not intuitively communicate that the number is negative. Appian therefore recommends using chart types such as bar, column, or line charts for negative values. A column chart is particularly effective when users need to see data extending above and below zero because its numerical axis provides the necessary context. Good visualization design should prevent users from drawing incorrect conclusions from a chart even when the underlying data values themselves are technically available.

Question 277. A dashboard compares 15 departments whose names are relatively long. Which chart type is generally preferable?

1. Pie chart with 15 slices
2. Scatter chart
3. Donut chart without labels
4. Bar chart

Correct Answer: 4. Bar chart

Explanation:

Bar charts use horizontal bars and provide more room for category labels, making them effective when category names are long or when there are relatively many categories. Appian’s design guidance specifically recommends a bar chart rather than a column chart when labels would otherwise need to be truncated or rotated. Horizontal labels are typically easier to read and compare. Developers should also consider applying a meaningful sort order, often descending by magnitude for bar charts, so important categories are immediately visible. Visualization usability depends not only on choosing a technically compatible chart but also on ensuring that users can read and compare the displayed values efficiently.

Question 278. A dashboard must show monthly revenue trends across several years, producing many sequential data points. Which chart type is generally well suited to this requirement?

1. Line chart
2. Pie chart
3. Boolean checkbox
4. Editable grid only

Correct Answer: 1. Line chart

Explanation:

Line charts are well suited to displaying trends across sequential time-based categories and can effectively present many data points. Monthly revenue over several years is a classic time-series scenario because users usually need to see direction, variation, and patterns rather than simply compare isolated categories. Appian’s chart guidance recommends line or area charts for trends over larger numbers of intervals, while column charts are often more suitable when the number of time intervals is relatively small. Developers should maintain a logical chronological sort order and provide sufficient axis and label context so users can correctly understand the progression represented by the chart.

Question 279. What is the purpose of a!measure() when configuring a records-powered chart?

1. To define a security group for chart viewers
2. To define a numerical calculation such as COUNT, SUM, or another supported aggregation over a record field
3. To configure a site page URL
4. To create a process instance for each chart value

Correct Answer: 2. To define a numerical calculation such as COUNT, SUM, or another supported aggregation over a record field

Explanation:

The a!measure() configuration defines the numerical value that a records-powered chart, KPI, or aggregate record query should calculate. A measure typically specifies a record field or related record field, an aggregation function, and an alias. It can also include filtering so only particular records contribute to the calculation. For example, a sales chart might use a SUM measure over revenue, while a support dashboard could use a COUNT measure for cases. Measures work together with groupings: the grouping determines how records are categorized, while the measure determines what numerical calculation is displayed for each category.

Question 280. A developer wants a chart showing total sales revenue for each product category directly from a record type. What configuration is MOST appropriate?

1. Create one process model for every category
2. Query all sales into text and manually draw the chart
3. Use the record type as the chart data source, group by product category, and define a SUM measure for sales revenue
4. Store the category names in an email template

Correct Answer: 3. Use the record type as the chart data source, group by product category, and define a SUM measure for sales revenue

Explanation:

Records-powered charts allow developers to configure aggregation directly from a record type. The product category field can be defined as the primary grouping, which determines the categories shown in the visualization. A SUM measure over the sales-revenue field then calculates the numerical value for each category. Developers can additionally configure sorting, data limits, links, and secondary grouping when supported by the selected chart type. This approach avoids manually querying and restructuring data solely to build the visualization and takes advantage of Appian’s record data fabric. Related record fields can also participate in supported chart groupings and measures.