In this episode of Appian Rocks, Stefan, Sandro, and Marcel tackle the controversial role of artificial intelligence in process implementation projects. While acknowledging AI’s impressive capabilities, they warn against the industry’s tendency to treat it as a universal solution. What demos well in sales meetings often falls short in practice, producing answers that only sound competent. The hosts argue that uncritical adoption leads to laziness, outsourcing of judgment, and a dangerous decline in deep problem-solving skills.
Marcel frames the issue as the “hammer and nail” problem: with AI marketed as the hammer, everything starts looking like a nail. This obsession can stifle thoughtful analysis and push teams to skip the hard work of understanding processes. Stefan illustrates this with a client case where rethinking and simplifying steps—without AI—halved the workload. The real benefit came not from automation but from owning the thinking and redesign. If a team relies on a chatbot instead, it risks losing both control and learning.
Still, the hosts emphasize that AI has valuable use cases, particularly where input is noisy or unstructured. Summarizing long documents, extracting fields from messy scans, or parsing communication are areas where probabilistic language models excel. But when data is already structured and clear, adding AI can actually reduce quality. As Stefan puts it, “the best part is no part”—if a step adds no value, eliminate it rather than overengineering with AI.
The conversation then broadens to the societal and environmental costs of AI overuse. Marcel highlights the immense energy and water consumption of data centers, noting that a single AI query is vastly more resource-hungry than a standard Google search. Sandro compares the phenomenon to refrigerators: once they became widespread, people stopped considering older preservation methods and even began misusing fridges for foods that spoil faster inside them. Likewise, if developers only learn to solve problems through AI, they may never develop alternative methods, filling the industry with people who know no tools beyond the “fridge.”
The panel also warns about economic risks. Current AI feels cheap because of heavy investment subsidies, but providers will eventually move to value-based pricing, charging for “man-hours saved.” This could trap organizations in costly dependencies once AI is deeply integrated into core processes. Consultants, they argue, must therefore frame adoption not only around use-case justification but also total cost of ownership, including volatile token-based pricing.
In closing, the hosts underline that AI should be one tool among many. Its convenience is undeniable, but convenience alone is no justification. In low-code environments like Appian, the temptation to lean on AI for speed is strong, yet true transformation still requires creativity, critical analysis, and ownership of solutions. Overuse risks fragile systems and a loss of craft. For now, they agree: AI is powerful and promising, but it must be applied sparingly, thoughtfully, and only where it adds real value.

Intro
In this episode of Appian Rocks, Stefan turns the spotlight on one of the most fundamental aspects of Appian development: expressions. Though they often operate behind the scenes, expressions power nearly every part of an Appian application—from interfaces to process models, decision logic to integrations. With the right approach, expressions can elevate a project’s maintainability, performance, and developer experience. But when misused, they can quickly become a source of confusion and technical debt.

TL;DL
Expressions are the lifeblood of Appian applications. In this episode, Stefan explains how to write clean, reusable, and performant expressions, shares practical tips for improving readability and maintainability, and discusses common mistakes that Appian developers should avoid.

On the role of expressions in Appian
Expressions in Appian are not just scripting snippets—they’re integral to building dynamic and flexible applications. Stefan emphasizes the importance of understanding the typed expression language deeply, especially when working with complex data structures. Expressions are used across every layer of an application, which makes writing clean and modular logic not just a best practice, but a necessity for scalability and collaboration.

Writing reusable expression rules
A major theme of the episode is the value of modularity. Stefan encourages developers to think of expression rules like functions: small, focused, and parameterized. Avoiding hardcoded logic and opting for reusable rules makes applications easier to update and test. Clear parameter naming and avoiding generic inputs like pv!input are also highlighted as critical for long-term maintainability.

Design and performance best practices
Stefan discusses how poor design choices—like deeply nested logic or repeated inline expressions—can quickly degrade both the performance and readability of applications. Instead of duplicating logic, developers should extract reusable patterns into separate expression rules. He also stresses the importance of minimizing rule chaining and understanding how and when expressions are recalculated, especially in interface contexts where performance can be affected by unnecessary re-evaluation.

Making expressions readable and maintainable
Readability is another key theme. Stefan suggests using tools like a!localVariables() to better structure logic in interfaces and avoid clutter. He cautions against overusing if() when constructs like a!match() or choose() would be clearer and more concise. Commenting logic is encouraged—especially for nested or non-obvious sections—to help both current and future developers navigate the application more effectively.

Collaboration and team alignment
Since expressions are touched by many developers over the course of a project, Stefan advocates for team-wide standards and code reviews specific to expression logic. Naming conventions, centralized utility rules, and internal documentation all contribute to making shared codebases more understandable. He emphasizes that expressions are not just technical elements—they’re collaborative artifacts that should reflect collective understanding and intentional design.

Avoiding common pitfalls
The episode wraps up with a discussion of mistakes Stefan frequently sees: expression rules that try to do too much, hardcoded assumptions that limit reuse, and dynamic evaluation bugs caused by lack of context awareness. His advice: keep logic modular, test thoroughly, and never underestimate the power of a well-named rule and a thoughtful comment.

In this episode of Appian Rocks, host Stefan explores the power and practicality of feature flags within Appian applications. Speaking from experience, he walks through what they are, why they matter, and how developers can use them to build more flexible, reliable, and scalable solutions.

TL;DL
Feature flags are a game-changer in Appian development, enabling controlled feature rollouts, safer deployments, and faster iteration. Stefan explains their role in dynamic application behavior, implementation strategies, and best practices, while offering insights into real-world usage and common pitfalls to avoid.

What feature flags are and why they matter
Feature flags allow developers to turn parts of their application on or off without needing a redeployment. This simple but powerful concept enables greater flexibility during development and release cycles. Rather than bundling all changes into a single deployment, teams can control exposure to features at runtime, making it easier to test, roll out gradually, or disable functionality if something goes wrong.

How they improve agility and reduce risk
Using feature flags helps teams iterate faster by decoupling feature availability from code releases. Developers can safely merge code for in-progress features into the main branch and enable them only when ready. This reduces pressure on deployment windows and adds a layer of safety in production environments. It also allows non-technical stakeholders to participate in controlling features through configuration, rather than relying on new deployments.

How to implement them in Appian
In Appian, feature flags are often implemented using constants, CDTs, or expression rules that evaluate whether a feature should be enabled. These flags can be referenced in interfaces, processes, or decisions to control application behavior dynamically. Stefan emphasizes the importance of centralizing flag definitions and maintaining clarity in how they’re used across the application, ensuring they’re easy to audit and update.

The risks and how to manage them
While feature flags offer flexibility, they come with the risk of creating technical debt if not managed properly. Flags that are never removed or poorly documented can clutter the application and lead to confusion or bugs. Stefan recommends building flag lifecycle management into development workflows—tracking which flags are active, which are temporary, and when they should be retired. Teams should also be aligned on naming conventions and ownership responsibilities to avoid surprises.

Real-world experience and team practices
Stefan shares insights from real-world projects where feature flags helped manage complex deployments and user-specific rollouts. He discusses how teams coordinate around flag usage, how flags are used to toggle between different integrations, and how they can improve the overall developer experience. The key, he notes, is striking a balance between power and discipline—using flags strategically, not as a shortcut for poor planning.

A Task is a Task… Or is It?

On the latest episode of Appian Rocks, I sat down with Sandro and Marcel to tackle a long-standing debate in the Appian world: User Input Tasks vs. Database Tasks.

At first glance, it seems simple—tasks are things people do in a process. But should we store and manage them inside the process model or in an external database? That’s where things get complicated.

What Actually Is a Task?

Marcel kicked things off by questioning whether every process step is a task. In short, no. A process can involve automated actions (system-driven) and human tasks (where someone makes a decision). In Appian, these are typically User Input Tasks—but sometimes, we need a more flexible approach.

User Input Tasks vs. Database Tasks

– User Input Tasks (UITs): Managed by Appian’s process engine, providing built-in assignment, escalation, and tracking. Great for structured workflows.

– Database Tasks (DB Tasks): Stored in a database, offering flexibility but requiring custom-built task management. Often favored by developers from traditional backgrounds.

The key takeaway? UITs handle structured processes well, while DB Tasks are better for case-driven workflows. The problem arises when teams mix both approaches, leading to complexity and redundancy.

When Does It Matter?

If you’re managing millions of tasks (like Joe Longworth in Episode 20), UITs might struggle, and DB Tasks can scale better. But for most use cases, UITs prevent unnecessary complexity—unless your process is inherently dynamic.

Another challenge? Cross-application task lists. If every Appian app implements DB Tasks differently, you lose the ability to provide users with a single, unified task list.

What’s the Right Approach?

There’s no one-size-fits-all answer, but here’s our advice:

– If UITs work for your process, use them.
– If your workflow is case-driven, DB Tasks might make more sense.
– Don’t mix both unless you really know what you’re doing.
– Ultimately, good Appian practitioners challenge assumptions. It’s not about what’s easy to build—it’s about what truly optimizes the process.

What do you think? Drop us a comment, and check out the full episode for the deep dive!