Common Client Requests That Can Hurt Performance in Appian

When developing applications on Appian, it’s common for clients to ask for features or capabilities that sound great on paper but can lead to performance issues, especially as the volume of data grows. As a developer or business analyst, it’s essential to identify these requests early and explain why they might not be the best choice for the system’s performance. Below are several common things clients may ask for that, when implemented without proper considerations, can negatively impact the application’s speed, scalability, and overall performance.


1. Displaying Large Datasets All At Once

The Request:

Clients often want to display large datasets (e.g., thousands of rows in a grid or table) in real-time without any filtering or pagination. The reasoning is often to provide users with all the information at once for faster decision-making.

Why It’s a Problem:

Loading a huge amount of data in a single request can severely impact performance:

  • Browser rendering time: Appian interfaces are rendered on the client-side (in the browser). Large datasets with many rows and columns can slow down the page load time, making the application sluggish and potentially unresponsive.
  • Server load: Retrieving large datasets from the server places significant load on the Appian server, especially if complex queries or calculations are involved.
  • UI responsiveness: The more data that is loaded and rendered, the more likely it is that users will experience lag, unresponsiveness, or even crashes, especially on lower-end devices or browsers.

The Solution:

Instead of loading all data at once, it’s best to:

  • Use pagination or lazy loading so that only the data the user needs is loaded at any given time.
  • Implement filters and search functionality to help users find the data they are looking for without overwhelming the UI with all available records.

2. Displaying Too Many Columns in Grids or Tables

The Request:

Clients might request to display a large number of columns in a grid or table to show as much information as possible at once, believing that users will benefit from seeing everything in one glance.

Why It’s a Problem:

A table with too many columns can:

  • Force horizontal scrolling, which negatively affects user experience, especially on mobile or smaller screens.
  • Increase page load time because the browser must render and format all columns.
  • Degrade performance if complex data types (e.g., rich text, documents) are displayed in many columns.

The Solution:

  • Prioritize the most important data and avoid showing everything at once. Display only the most relevant columns for the user’s immediate needs and offer expandable views or tooltips for additional information.
  • Use dynamic visibility in Appian to only show columns that are necessary based on user context, such as permissions or role-specific views.
  • Provide a “Show More” button or accordion-style expandable sections for non-essential columns or data.

3. Real-Time Updates with Heavy Server Calls

The Request:

Clients may want certain parts of their application to update in real-time — for example, a grid displaying live data from an external system or frequent task assignments — without manual intervention.

Why It’s a Problem:

While real-time updates can enhance the user experience, frequent server calls can:

  • Increase load on the server and network bandwidth, especially if the updates are being processed every few seconds.
  • Lead to poor user experience when multiple components or pages are refreshing simultaneously.
  • Overwhelm the system if there’s no mechanism to throttle or batch updates, especially in high-volume scenarios.

The Solution:

  • Use batch processing or scheduled updates for non-urgent data rather than real-time updates.
  • If real-time updates are absolutely necessary, implement a mechanism to limit the frequency of updates (e.g., refresh data every minute instead of every second).
  • Consider using Appian’s event-driven architecture (e.g., using a!refresh() for specific components) rather than refreshing the entire page.

4. Complex, Nested Expressions or Rules

The Request:

Clients often ask for complex calculations or nested expressions that may seem logical but are computationally intensive. These could involve deep nesting of rules or large arrays being manipulated through multiple layers of expressions.

Why It’s a Problem:

  • Performance bottlenecks: Complex, deeply nested logic requires more processing time both on the Appian server and the client (browser). This can slow down the interface significantly, especially if many users are simultaneously executing these calculations.
  • Hard to maintain: Complex logic is difficult to maintain and debug, making it more likely to result in future performance problems as business logic evolves.

The Solution:

  • Simplify the logic: Break complex expressions into smaller, modular rules or functions that can be reused. This improves performance and makes the system easier to maintain.
  • Use Appian’s built-in functions instead of custom code whenever possible to leverage optimized, prebuilt performance.
  • If large datasets need to be processed, consider moving the logic server-side (in process models or as an API call) rather than executing it in the interface.

5. Unrestricted User Access to Data

The Request:

Clients may request to give all users unrestricted access to all records or data, believing that making everything available will simplify user experience and allow for more freedom.

Why It’s a Problem:

Unrestricted data access can cause:

  • Security risks: Sensitive or confidential data may be exposed to unauthorized users.
  • Performance degradation: When users have access to large datasets, every query can become a performance bottleneck, especially if the system needs to check permissions on every record for every user.

The Solution:

  • Implement role-based access control (RBAC) to restrict access to sensitive data based on user roles or specific permissions.
  • Use Appian’s record security model to define access at a granular level, ensuring only authorized users can view or modify specific records.
  • Index records properly in Appian to ensure that security checks do not unnecessarily slow down performance when filtering data.

6. Excessive Use of Document Management for Data Storage

The Request:

Clients might request to store large amounts of non-document data (such as lists or large datasets) in Appian’s document management system for ease of access, rather than using databases or record types.

Why It’s a Problem:

  • Document storage is not optimized for large data: Appian’s document management system is optimized for file-based data, not for structured, high-volume datasets like transactional data or lists.
  • Slower performance: Storing large amounts of non-document data in the document store can lead to slower retrieval times and higher storage costs.

The Solution:

  • Store structured data (like lists, logs, or transactional data) in Appian records or external databases rather than in document storage.
  • Use Appian’s database integration capabilities to manage large datasets that need to be accessed frequently or are transactional in nature.

7. Using Multiple Complex Process Models for Small, Simple Tasks

The Request:

Clients may request the creation of multiple process models for relatively simple tasks because they believe splitting the work will improve maintainability and control.

Why It’s a Problem:

  • Increased overhead: Each process model introduces additional overhead, including the need for more deployment, monitoring, and error-handling. Too many process models can lead to higher complexity and performance issues.
  • Difficulty in managing workflows: Having too many small, disconnected models can make the overall process harder to debug and optimize.

The Solution:

  • For small tasks, consider using a single process model that can handle all required logic in a straightforward, efficient way.
  • Use sub-processes where appropriate to break down tasks without creating excessive overhead.

8. Overuse of User Inputs and Interaction

The Request:

Clients might request interfaces with too many interactive elements, such as dropdowns, text fields, or buttons that are constantly updated based on user input. While this can create a highly dynamic and engaging UI, it can also cause performance issues.

Why It’s a Problem:

  • Excessive data binding: Each interaction might trigger a backend query or update, leading to unnecessary load and slower performance.
  • Overcomplicated UI: Too many inputs can confuse users and lead to an overwhelming interface. It may also make the app slower to render and process.

The Solution:

  • Limit interactive elements to only those necessary for the user’s task. Focus on delivering the most streamlined experience.
  • Use conditional logic or on-demand loading to only update components when needed, rather than constantly refreshing the entire page or interface.

Conclusion

While clients often have valid reasons for requesting certain features, it’s important to balance those needs with the realities of performance and scalability. If you need consultants to guide you through your Appian implementation, reach out today!

Leave a Reply

Your email address will not be published. Required fields are marked *