View Full Appian ACD201 Exam Dumps and Practice Test Dumps.

Question 281. What is the PRIMARY purpose of a custom record field in Appian?

1. To replace the primary key of every record type
2. To create a calculated or transformed value from existing record data without requiring the value to exist in the source system
3. To automatically create a new database table
4. To define site-navigation permissions

Correct Answer: 2. To create a calculated or transformed value from existing record data without requiring the value to exist in the source system

Explanation:

Custom record fields allow developers to derive additional information directly within an Appian record type. Unlike ordinary record fields, which map to values stored in the source system, custom record fields can transform, aggregate, combine, or calculate values that exist only within the record type. Examples include combining first and last names, calculating a case’s age, or counting related orders. Once created, custom fields can be referenced in application interfaces and may be used for supported sorting and filtering scenarios. They help developers enrich the data fabric without requiring every derived business value to be persisted as another physical database column.

Question 282. When is a sync-time custom record field recalculated?

1. Every time a user moves the mouse
2. Only when the application is deployed
3. Once when the field is originally created and never again
4. When the record type synchronizes its data**

Correct Answer: 4. When the record type synchronizes its data

Explanation:

A sync-time custom record field is evaluated as part of record synchronization. Its value is calculated during events such as a scheduled sync or smart-service-triggered sync and is then stored with the optimized record data. Because the value does not need to be recalculated every time an application references the field, sync-time fields can provide fast retrieval for calculations that do not need continuous real-time reevaluation. They are commonly appropriate for formatting, concatenation, and conditional classifications based on data in the base record type. Developers should use real-time evaluation instead when the required result must change independently of synchronization.

Question 283. A developer needs a custom field named Days Open that should change as today’s date changes, even when the underlying case has not been modified. Which approach is BEST?

1. Configure a real-time custom record field
2. Store the value permanently in a site object
3. Create a new security group each day
4. Use a sync-time field without scheduling future syncs

Correct Answer: 1. Configure a real-time custom record field

Explanation:

Real-time custom record fields are evaluated whenever they are actively referenced, making them appropriate for calculations whose answer can change even when source data remains unchanged. A Days Open value is a good example because the result depends on the current date as well as the case’s creation date. Appian specifically identifies relative-date calculations as a common real-time custom-field use case. A sync-time calculation would retain its previous result until another synchronization occurred. Real-time evaluation therefore gives the application a current result whenever the field appears in a grid, chart, query, or other supported application context.

Question 284. What is the maximum number of custom record fields that can be created on a single supported record type?

1. 10
2. 20
3. 40
4. 100

Correct Answer: 3. 40

Explanation:

Appian allows a maximum of 40 custom record fields on a supported record type. This limit works together with the overall field limit for the record type, so developers cannot assume that all 40 custom-field slots will always be available. Custom record fields are powerful because they can add derived values and calculations directly to the data model, but they should still be created deliberately. An excessive number of calculated fields can make the data model harder to understand and maintain. Senior developers should identify reusable business calculations that provide meaningful value rather than moving every interface-specific expression into the record type.

Question 285. A record type already contains 98 source fields. Assuming no other limitation applies, how many additional custom record fields can be created before reaching Appian’s total field limit?

1. 40
2. 20
3. 98
4. 2

Correct Answer: 4. 2

Explanation:

Supported synced and unsynced record types have a maximum of 100 fields in total, while custom record fields also have their own maximum of 40. These limits are shared in practice because source fields and custom record fields all contribute to the total field count. Therefore, a record type with 98 existing source fields has room for only two additional custom record fields before reaching the 100-field overall limit. This is important during data-model design because a very wide source table can significantly reduce the number of derived fields that can be added directly to the record type.

Question 286. How deeply can a real-time custom record field reference related record fields through nested relationships?

1. One relationship level only
2. Up to five relationship levels
3. Exactly ten relationship levels
4. There is no relationship-depth limit

Correct Answer: 2. Up to five relationship levels

Explanation:

Real-time custom record fields can traverse related record fields through as many as five relationship levels. This provides considerable flexibility when a calculation needs information from connected business entities. For example, an Order record might reference a Customer, which references a Region, allowing the custom field to use information across multiple relationships. If the required logic would traverse more than five levels, Appian recommends reconsidering the design, such as by creating intermediate custom fields that reduce the required depth. Deep relationship chains can also make a data model difficult to understand, so developers should keep relationships intentional and business-oriented.

Question 287. What is the PRIMARY purpose of a sync filter on an Appian synced record type?

1. To determine which source rows are synchronized and made available in the record type
2. To change the permissions of individual records
3. To hide interface components from users
4. To select which process models can write data

Correct Answer: 3. To determine which source rows are synchronized and made available in the record type

Explanation:

Sync filters restrict the source rows that Appian synchronizes into a synced record type. They are useful when an application needs only a subset of a larger source dataset, such as recent orders or active cases. Filtering unnecessary data can shorten synchronization times, reduce the amount of data maintained in Appian, improve query efficiency, and help applications scale more effectively. Sync filters are not security controls; developers must still configure record-level and object security separately. Their purpose is to define the dataset that exists in the synced record type rather than merely hiding records from particular users after synchronization has occurred.

Question 288. When are sync-filter conditions evaluated?

1. Only when the record type is first created
2. Only during application deployment
3. Only when a user opens the record list
4. During applicable full, incremental, and smart-service sync operations

Correct Answer: 1. During applicable full, incremental, and smart-service sync operations

Explanation:

Sync filters participate in synchronization rather than normal interface rendering. Appian evaluates the filter conditions when the record type synchronizes, including applicable full, incremental, and smart-service syncs. Rows that do not satisfy the filter are excluded from the synced dataset. This timing matters because changing a filter expression or a value used by the filter does not necessarily change existing synced data instantaneously without synchronization. Developers should therefore consider the application’s synchronization strategy together with its filtering requirements. A filter based on changing business criteria must be reevaluated often enough for the resulting synced dataset to remain accurate for users.

Question 289. Which capability is available in sync-filter Expression mode but not provided by Basic mode’s automatic filter combination?

1. Filtering any data at all
2. Combining multiple conditions using custom AND or OR logical expressions
3. Synchronizing database data
4. Referencing source fields

Correct Answer: 4. Combining multiple conditions using custom AND or OR logical expressions

Explanation:

Basic-mode sync filters provide a guided configuration experience and automatically combine multiple configured filters with AND logic. Expression mode provides greater control by allowing developers to construct filters using a!queryFilter() and a!queryLogicalExpression(), including custom combinations of AND and OR conditions. However, Expression mode does not support filtering through a relationship, which is a capability available in Basic mode for supported database-backed scenarios. Senior developers should choose the mode according to the business requirement: Basic mode works well for guided source or relationship filtering, while Expression mode is preferable when more sophisticated Boolean filtering logic is required.

Question 290. A Comment record type uses a sync filter based on its relationship to Open Cases. A related case is changed from Open to Closed. When are the now-ineligible comments removed from the Comment record type because of that relationship filter?

1. Immediately whenever the Case interface refreshes
2. When a full sync occurs on the Comment record type
3. Only when the application is redeployed
4. They can never be removed

Correct Answer: 1. When a full sync occurs on the Comment record type

Explanation:

Relationship-based sync filters have an important timing consideration. If the related data changes in a way that means base records should no longer satisfy the filter, the base record type does not necessarily remove those rows immediately. Appian documents that relationship-based filtering is reapplied to the base record type during a full sync. In the example, changing a Case from Open to Closed does not immediately remove its Comments solely because of the relationship filter. A full sync of the Comment record type is needed. Developers should account for this behavior when designing applications where relationship-based filtering must closely track source changes.

Question 291. A sync filter uses today() to include only records due today. What should the developer understand about this filter?

1. The value automatically changes continuously without any synchronization
2. The filter is evaluated once per application version
3. today() resolves when the sync runs, so another sync is needed as the date changes
4. Relative-date functions are never allowed in sync filters

Correct Answer: 2. today() resolves when the sync runs, so another sync is needed as the date changes

Explanation:

A relative-date expression such as today() is evaluated to a specific value at the moment the synchronization runs. The synced dataset does not automatically change at midnight merely because the calendar date changes. For example, a record due tomorrow will not automatically appear when tomorrow arrives unless another applicable sync reevaluates the filter. Appian therefore recommends scheduling appropriate full or incremental synchronization when relative dates determine which records belong in the synced dataset. This behavior differs from real-time custom-field calculations, which are designed to reevaluate when referenced rather than only when the record type synchronizes.

Question 292. What does a “Failed and Skipped” record sync status indicate?

1. The previous synced data remains available, but it may now be outdated
2. All previously synced data has been permanently deleted
3. The record type has automatically switched to direct data access
4. Every dependent record type is automatically deleted

Correct Answer: 3. The previous synced data remains available, but it may now be outdated

Explanation:

A Failed and Skipped status means Appian encountered a sync failure but skipped the unsuccessful synchronization according to the configured availability options. The record type continues to use the data that was successfully synchronized before the failure, so record queries can continue working. The tradeoff is freshness: because the latest sync did not complete, the available data may no longer reflect the current source. This behavior can improve application availability during temporary source or synchronization problems. Developers and administrators should still investigate the error and restore successful synchronization rather than assuming that continued query availability means the data is fully current.

Question 293. What is a major consequence when a synced record type has a plain “Failed” sync status?

1. Users receive the previous data indefinitely with no impact
2. Only the record type’s description becomes unavailable
3. The record type is automatically converted to a legacy record
4. The synced record data is unavailable, and queries or dependent components may fail

Correct Answer: 1. The synced record data is unavailable, and queries or dependent components may fail

Explanation:

A Failed sync status indicates that synchronization failed in a way that leaves the record data unavailable. Queries to that record type will not return normal data, the record list becomes unavailable, and grids or charts depending on the record type can produce errors. The impact can extend through relationships as well. If another record type query requests related fields from the failed record type, that query may also fail. Appian generally recommends identifying the root cause and performing a successful full sync to restore availability. Developers should therefore treat sync health as an operational dependency of applications that rely heavily on optimized record data.

Question 294. What does the “Failed and Recovering” sync status mean?

1. Appian has permanently stopped attempting to synchronize the record type
2. A recovery sync is expected to start automatically after certain connection-related sync failures
3. The record type is being deleted
4. A developer must manually recreate the record type before any data can return

Correct Answer: 4. A recovery sync is expected to start automatically after certain connection-related sync failures

Explanation:

Failed and Recovering indicates that a qualifying smart-service or incremental sync failed because of a source connectivity problem and that Appian will attempt a recovery sync. The recovery mechanism is designed to restore the record type by synchronizing the required source data automatically once the recovery process begins. This status is available only when recovery syncs have been enabled for the record type; Appian notes that the feature is not enabled by default on new record types. Recovery improves resilience, but developers should still monitor recurring failures because repeated connectivity problems may indicate an issue with the database, network, API, or external source itself.

Question 295. What is true about the “Skip failed full and incremental syncs” availability option for newly created record types?

1. It is enabled by default on new record types
2. It can only be configured for legacy record types
3. It permanently disables all future full syncs
4. It forces Appian to discard previously synchronized data after an error

Correct Answer: 3. It is enabled by default on new record types

Explanation:

Appian enables the option to skip failed full and incremental syncs by default for newly created record types. When the option applies and a synchronization fails, Appian can continue serving the previously available synchronized data instead of making the record type immediately unavailable. The resulting data may be stale, so the failure still requires investigation. Availability options are designed to help teams choose an appropriate balance between continuous application access and strict freshness requirements. Senior developers should understand the operational expectations of the application before changing these settings, particularly for business processes where outdated data could have significant consequences.

Question 296. Which statement BEST describes a scheduled full sync?

1. It processes only one changed record at a time
2. It can synchronize the entire source dataset and reflect created, updated, and deleted source data
3. It executes automatically after every interface interaction
4. It can run only when initiated by a system administrator manually

Correct Answer: 2. It can synchronize the entire source dataset and reflect created, updated, and deleted source data

Explanation:

A full sync refreshes the record type using the source data as a whole. Appian describes the process as replacing the existing synchronized data with the latest data available from the source, allowing created, updated, and deleted information to be reflected. Full syncs can be scheduled, commonly once per day, and Appian recommends running them outside peak business periods when possible because they can process significant volumes of information. If an external system deletes records, periodic full synchronization can be particularly important because incremental synchronization primarily focuses on changed data identified through the configured last-modified mechanism.

Question 297. Source records are frequently created and updated by an external system, and the table contains a reliable last-modified timestamp. Which synchronization strategy is especially useful for keeping Appian current without repeatedly processing the entire source?

1. Disable synchronization
2. Run only application deployments
3. Use scheduled incremental synchronization based on the last-modified field
4. Store all source rows in process variables

Correct Answer: 4. Use scheduled incremental synchronization based on the last-modified field

Explanation:

Scheduled incremental synchronization is designed for situations where external systems regularly create or update source records and the source provides a reliable field indicating when each record was last modified. Appian can use that field to identify and synchronize changes since the previous applicable sync rather than processing the entire dataset every time. This can provide fresher data with less work than frequent full synchronization. If external systems also delete rows, Appian recommends combining incremental synchronization with periodic full syncs so deletions can also be accurately reflected. The synchronization schedule should match the business requirement for freshness and expected change volume.

Question 298. The Sync Records smart service is executed for a record type, but the executing user does not have Viewer permission to that record type. What happens?

1. The sync executes with System Administrator access automatically
2. The sync is not triggered and the node can fail with an exception
3. The user automatically receives Viewer permission
4. The record type’s security is ignored for smart services

Correct Answer: 3. The sync is not triggered and the node can fail with an exception

Explanation:

By default, the Sync Records smart service runs under the identity of the user who starts the process. That user must have at least Viewer permission to the record type being synchronized. If the permission is missing, Appian does not trigger the sync, and the smart-service node fails and pauses the process with an exception. This illustrates the importance of considering execution identity as part of process and data-fabric architecture. A process may be correctly configured functionally but still fail when executed by a user whose object permissions do not satisfy the requirements of the referenced record type.

Question 299. What additional configuration is required to use Sync Records by identifier with a service-backed record type?

1. A sync-by-identifier expression capable of retrieving the requested records from the service
2. A process-report file
3. An editable grid
4. A data store entity for every returned value

Correct Answer: 2. A sync-by-identifier expression capable of retrieving the requested records from the service

Explanation:

For a service-backed record type, Appian needs to know how to request specific records from the external service when the Sync Records smart service supplies identifiers. This requires a sync-by-identifier expression. Without that expression, Appian cannot translate the identifiers into appropriate service requests, so the synchronization cannot execute correctly and the node fails. The existing record type can remain available after this type of configuration error. The expression typically relies on an integration to communicate with the external source, so developers must also account for authentication, service availability, error propagation, and the external API’s expected request structure.

Question 300. A large order table receives frequent updates and occasional deletions from an external system. The application only needs recent orders and must also display a calculated Days Since Order value. Which design BEST uses Appian data-fabric capabilities?

1. Synchronize all historical rows, use no scheduled syncs, and calculate every value manually in each interface
2. Use only a process variable containing the entire order table
3. Disable optimized data access so every screen retrieves the entire source directly
4. Use sync filters for relevant orders, scheduled incremental syncs for frequent changes, periodic full syncs to capture deletions, and an appropriate custom record field for the calculated value

Correct Answer: 1. Use sync filters for relevant orders, scheduled incremental syncs for frequent changes, periodic full syncs to capture deletions, and an appropriate custom record field for the calculated value

Explanation:

This scenario benefits from combining several data-fabric capabilities rather than solving every requirement at the interface layer. Sync filters can restrict synchronized data to the recent orders the application actually uses, reducing volume. Incremental synchronization can efficiently capture frequent source updates when a reliable last-modified field exists, while periodic full syncs help ensure externally deleted rows are also reflected. A custom record field can centralize the Days Since Order calculation instead of duplicating that expression in every interface. Together, these features improve scalability, maintainability, data freshness, and consistency while keeping the record type aligned with the application’s actual business needs.