ACD200 Practice Questions

The BOOKID field is intended to be the unique identifier, or primary key, for the book data. According to Appian best practices for data design, the primary key for a Custom Data Type (CDT) that is mapped to a database table should be an auto-generating integer. The Number (Integer) data type is the correct selection to implement this. When this type is chosen and designated as the primary key in the CDT designer, Appian configures the underlying database column to automatically increment. This ensures a unique numeric value is generated for each new record, which is the standard and most efficient method for managing primary keys.

1. Appian Documentation: In the section on creating a data type from scratch

the documentation specifies the configuration for a primary key field. It states

"For Type

select Number (Integer). This is the only type that can be used for a primary key." This directly supports the choice of Number (Integer) as the required type for a primary key field like BOOKID.

Source: Appian 23.4 Documentation

"Create a Data Type from Scratch

" Step 6 in the "Create a data type" procedure.

2. Appian Academy: The Appian Developer learning path includes modules on data design and persistence. In the lessons covering the creation of CDTs

the standard practice demonstrated is to create an "id" field

set its type to Number (Integer)

and then select the "Primary Key" and "Auto-generate the next value" options. This reinforces that Number (Integer) is the designated type for auto-incrementing primary keys.

Source: Appian Academy

Appian Developer Learning Path

"Data with CDTs" module.

A database trigger is the most efficient design as it operates directly at the data source level, independent of the Appian execution engines. When a record is modified via any Appian action, the database trigger automatically captures the changes and writes them to an audit table within the same database transaction. This approach completely offloads the auditing logic from the Appian application, resulting in the lowest possible performance impact on Appian's servers. The auditing process is transparent to the Appian objects (e.g., process models, interfaces) that perform the data modification, ensuring minimal overhead and complexity within the application itself.

1. Appian Corporation. (2023). Data-Centric Design. Appian Documentation. In the "Leverage the Database" section

the documentation advises

"Leverage the database for what it does best: managing and manipulating large sets of data... For example

if you need to update thousands of rows in a database table

it is much more efficient to call a stored procedure from Appian than it is to loop through those updates in a process model." This principle directly supports offloading the row-level audit task to a database trigger for maximum efficiency.

2. Appian Corporation. (2023). Record Events. Appian Documentation. This document describes the Appian-native approach of using record events to trigger a process. While a valid pattern

this method still consumes Appian application resources to handle the event and execute a process

making it less efficient and having a greater impact than a database trigger that operates outside the Appian execution engine.

3. Silberschatz

A.

Korth

H. F.

& Sudarshan

S. (2019). Database System Concepts (7th ed.). McGraw-Hill. Chapter 8

"Advanced SQL

" discusses the use of triggers for maintaining data integrity and creating audit trails. The text explains that triggers are executed by the database system automatically as a part of the modifying transaction

which is inherently more efficient for auditing than an external application-layer process.

To execute an Appian Web API, the calling user or service account must have a minimum of Viewer permissions to the Web API object. This aligns with the principle of least privilege, granting only the necessary rights to invoke the endpoint without allowing modification. Higher permission levels, such as Editor or Administrator, also permit execution but provide additional capabilities (e.g., editing the object's definition, managing security) that are not required for an end user to simply call the API. Therefore, Viewer is the correct minimum privilege level.

1. Appian Corporation. (2023). Web API Object. Appian 23.4 Documentation. In the "Security" section

it states: "Users must have at least Viewer permissions to the web API to execute it."

2. Appian Corporation. (2023). Object Security. Appian 23.4 Documentation. This document outlines the standard permission levels (Administrator

Editor

Viewer

Deny) and their general functions

reinforcing that Viewer permissions are intended for users who need to see or use an object at runtime without modifying it.

A database view is the recommended and most performant solution for combining data from multiple tables into a single, denormalized source for Appian. This approach directly addresses the requirement to join five large tables. The view encapsulates the complex join logic at the database level. This view can then be used as the source for an Appian record type with data sync enabled. This pattern satisfies the performance and data freshness requirements by querying the fast, cached data source and refreshing it on the specified two-hour interval, avoiding costly real-time joins for every data request.

1. Appian Documentation

"Record Type Object." In the section describing the data source for a record type

the documentation explicitly recommends this pattern: "If your record data is spread across multiple tables

create a database view to combine the data into a single source for your record type."

2. Appian Documentation

"Data Sync." In the section "When to Use Data Sync

" the documentation lists key use cases that match the scenario

including: "You want to improve the performance of your records

reports

and queries" and "Your data doesn't need to be real-time." This confirms that using a view as a source for a synced record is the correct pattern.

3. Appian Documentation

"Data Modeling." The best practices for data modeling emphasize creating performant data structures. Using a view to denormalize data for read-heavy operations is a standard technique to improve query performance

which is the top priority in the question.

A Servlet plug-in exposes a URL endpoint that executes custom Java code on the server when accessed. This allows it to perform background jobs when triggered by an external system or scheduler. Unlike other plug-in types, it is not designed to be directly available within the expression editor (like a Function plug-in), the process model palette (like a Smart Service plug-in), or as a Connected System template. This architecture meets all the requirements for a background job that is isolated from the standard Appian design objects mentioned in the question.

1. Appian Corporation. (2023). "Servlet Plug-ins". Appian 23.4 Documentation. Appian Corporation. This source states

"Servlet plug-ins allow developers to extend Appian by exposing a URL that executes custom Java code. This can be useful for a number of purposes

such as... providing a web service that can be called by an external system."

2. Appian Corporation. (2023). "Plug-in Types". Appian 23.4 Documentation. Appian Corporation. This overview document distinguishes the purposes of different plug-ins

confirming that Function

Smart Service

and Connected System plug-ins are used specifically in the areas the question explicitly excludes.

A low completion percentage for frequently executed process models is a strong indicator of a design-related performance issue. It means that a significant number of process instances are starting but not finishing, remaining active in the system's memory. These lingering instances consume server resources, and as their numbers grow, they can lead to system-wide performance degradation. This problem is typically caused by design flaws such as unhandled exceptions, logic errors that lead to infinite loops, or poorly designed user tasks that are frequently abandoned. Rectifying this requires analyzing and redesigning the process models to ensure they run to completion efficiently.

A. An HTTP 500 status code indicates an "Internal Server Error" on the external system being called, not a performance issue originating from the Appian application's design.

C. An increase in the number of assigned tasks suggests higher user adoption or workload, which is a measure of usage, not an inherent sign of performance degradation.

D. An increase in the number of application objects reflects the application's growth and complexity, not a direct indicator of a performance problem. A well-designed application can scale to many objects.

1. Appian Documentation

Process Model Metrics: The "Process Model Metrics" page in the official Appian documentation explains the significance of the completion rate. It states

"A low completion rate could indicate that users are abandoning the process

or that the process is frequently paused by exception." Both scenarios point to design flaws that need to be addressed. (See: Appian 23.4 Documentation

"Monitor" section

"Process Model Metrics" page).

2. Appian Documentation

Process and Report Performance: This documentation highlights factors affecting performance. The number of active processes directly impacts memory usage. A low completion rate in high-volume models leads to a rapid accumulation of active processes

which is a primary cause of performance degradation. (See: Appian 23.4 Documentation

"Appian Administration" section

"Process and Report Performance" page).

3. Appian Documentation

Integration Object: The documentation on integrations clarifies that HTTP status codes in the 5xx range represent server-side errors from the system being integrated with

confirming that this is an external issue. (See: Appian 23.4 Documentation

"Design Objects" section

"Integration Object" page

"HTTP Status Codes" subsection).

This scenario requires a mechanism that both interrupts a task after a specific duration and triggers an alternative process flow. An exception timer on the User Input Task is the correct implementation. When the 30-minute timer expires, the exception path is triggered, which cancels the active task, preventing the user from submitting. This exception flow can then be directed to a Send Email smart service to notify the supervisor. Because the main flow is bypassed, the subsequent node to save data to the database is never executed, fulfilling all requirements.

B. A quick task is designed for simple, immediate actions, not for a complex form-based review that requires the ability to save a draft and return later.

C. A send message event is used for inter-process communication. While it could be triggered by a timer, it would not cancel the original user input task, allowing a late submission.

D. An escalation can send a notification after a set time but does not interrupt or cancel the task. The technician could still complete the review after the 30-minute deadline has passed.

1. Official Appian Documentation

"User Input Task

" section on "Escalations and Exceptions": This section explicitly differentiates between the two. It states

"Exceptions are configured on the Exceptions tab of an activity. They allow you to redirect the process flow... When an exception is triggered

the activity is deactivated." This confirms that an exception timer (Option A) deactivates the task

while an escalation (Option D) does not.

2. Official Appian Documentation

"Ways to Trigger a Process

" section on "Timer": This documentation details how timers can be used to start a process or trigger an event within a process. It clarifies that a timer configured as an exception on a node will interrupt the node's execution

which is the required behavior.

3. Official Appian Documentation

"Quick Tasks": The documentation describes Quick Tasks as a way to "complete simple actions and tasks directly in Tempo

Sites

and embedded interfaces." This highlights their unsuitability for the described review process which implies a more complex form with draft functionality.