In this latest episode of the Appian Rocks podcast, hosts Stefan, Marcel, and Sandro tackle the complex reality of integrating AI into the Appian platform. Recorded in January 2026, the conversation highlights a growing tension between high-level marketing promises and the practical constraints faced by developers on the ground, particularly within the strictly regulated markets of Germany and the broader European public sector. Stefan shares his “stomach aches” regarding the pressure to sell Appian as an “Enterprise AI” tool when data protection laws often prohibit the use of foreign AI technologies in public services.

The discussion distinguishes between two main branches of AI: customer-facing capabilities, such as document extraction and semantic search, and developer-facing tools designed to accelerate the build process. While the hosts praise features like the AI-powered documentation chatbot for its immediate utility, they express skepticism regarding the “AI Composer”. Though the Composer can generate an application from a requirements document, the hosts argue that the output often lacks the long-term maintainability, scalability, and architectural integrity required for professional enterprise solutions.

A significant portion of the episode is dedicated to a “Quality of Life” wishlist, with the hosts urging Appian to prioritize fixing long-standing product deficits over adding more AI “hype”. Major pain points identified include the tedious nature of managing translation sets across multiple applications and the lack of automated schema management for record types. Sandro highlights the frustration of rigid UI alignment options, noting that achieving professional layouts often requires “hacky” workarounds. Additionally, the team requests simple yet impactful features like a native sticky footer and a fix for a persistent autocomplete bug that incorrectly selects items based on mouse cursor position.

The episode wraps up with a technical deep dive into the need for an application-scoped sandbox plugin environment. Such a feature would allow developers to extend the platform’s capabilities safely, ensuring that custom AI models or libraries can be used without compromising enterprise-level compliance across the entire environment. Ultimately, the hosts call for “a bit more love” for the day-to-day tools that keep developers efficient and happy.

In our latest episode, Sandro, Marcel, and I explored a topic crucial for anyone working with Appian: training and educating developers.

Many prospective clients approach us, noting Appian is a low-code/no-code platform and wondering if they even need to train their “citizen developers.” Our consensus? Training is absolutely essential.

The true value of a citizen developer is their functional, business-side knowledge. They can become a valuable team member and steer development because they know how the application is intended to be used. The ideal team is a mix—technical experts ensure a technically good application, and business experts ensure it solves the actual problem.

Being a developer, regardless of the technology, requires a specific approach. People need to understand how software in general works and become “software designers,” not just coders. A developer must be able to analyze a complex situation and turn something from a problem domain (like complaining about too many emails) into a solution domain (like reducing manual workload by 80%). A key indicator of a good potential developer is the capacity to ask clarifying questions instead of jumping straight into a solution based on vague or assumption-loaded descriptions.

The goal for training juniors is to get them to an Associate Certified Appian Developer level. Both traditional and non-traditional IT backgrounds need to understand processes and process-driven software, recognizing that a process has a lifecycle with a start and an end. Traditional IT professionals often grasp the technical context quickly, while non-traditional backgrounds often excel at understanding the messy human context in which Appian operates. Juniors must master methodical thinking and debugging, including knowing the Appian platform’s monitoring and debugging options.

We encourage juniors to try solving a problem on their own for 30–60 minutes, check the community, and then come to their lead prepared to explain: what they are trying to do, what they have tried so far, and what the current issue is. This structure helps them self-solve and makes the assistance more effective. Asking “why” repeatedly, a technique officially known as the “Five Whys Method,” can also help break a person out of a narrow view to fix the root cause.

We follow a structured training path. People first complete the Appian Developer Learning Path to understand the platform’s components and intended use. This is often followed by a one-week on-site boot camp where a group works on one application with a prepared use case. During the boot camp, we cover our internal developer’s wiki, including naming conventions and reusable components, ensuring a common understanding for working within our teams. Finally, working in teams and providing regular code review is crucial to avoid reinforcing bad habits, which is why training is expensive—it requires your best people.

Becoming a senior is less about writing quicker SAIL code and more about broadening context and developing consultancy skills. A senior needs to have empathy, understanding that the person paying for the solution has a valid problem and doesn’t necessarily speak your technical language. They also must recognize that process-orchestrating software is an organizational change, requiring an understanding of change management to design transparent processes that don’t frighten users. Seniors need to understand UX/UI design, business processes, and guesstimating non-functional requirements like performance and memory consumption. A true senior has experienced the pain of running something they coded in production and dealing with user issues, which enforces understanding of maintainability and responsibility.

We’re always happy to talk about these topics! If you have any questions, please feel free to send them in!

In this episode of Appian Rocks, Stefan, Sandro, and Marcel dive into a conversation that starts with the seemingly dull topic of software reviews but quickly evolves into a deep and thought-provoking discussion about ethics in digital process automation. Initially, they touch on the typical components of a code review—adherence to best practices, syntax, node counts in processes, and test cases. However, they challenge the narrow scope of this approach, questioning whether technical correctness alone is sufficient, especially when the software influences real-world decisions in complex environments.

The conversation shifts to the broader context in which applications operate, especially in public sector projects. The team notes that stakeholders such as the funding agency, the users, and the beneficiaries are often different entities, each with distinct priorities. This creates a tension where developers can find themselves caught in the middle. While developers are typically not policy makers, the code they write can enforce rules and decisions that significantly affect people’s lives. This leads to a central theme of the episode: software is not neutral. It embodies decisions, and those decisions can have ethical consequences.

They explore how public sector automation transforms discretionary, human-driven processes into rigid, rule-based systems. This transition, while increasing efficiency, risks stripping away the nuance and empathy that experienced civil servants once applied. For example, decisions about child support or eligibility for government aid, which were previously made by humans considering context and individual circumstances, are now reduced to logic gates and business rules. The trio argues that this change demands new layers of oversight—beyond testing whether a process works, teams must ask whether it works *fairly* and *justly*.

A particularly striking point raised is the lack of ethical audits in most software development projects. Stefan admits he’s never performed one, and the group collectively questions why such audits aren’t standard practice. Is it because they were never needed? Or is it because ethical responsibility was previously embedded in human roles and not in the tools themselves? They agree that developers, especially solution designers and business analysts, have a duty to consider the broader impacts of their implementations.

The discussion also touches on traceability and transparency. Marcel introduces the concept of traceability as a critical requirement, particularly in government software. Every feature in an application should be traceable back to a signed-off requirement to ensure accountability. This is essential not only for auditing but also for safeguarding citizens’ rights when decisions are automated. Transparency, too, is highlighted as a core value—systems should provide users with understandable explanations for decisions, such as why a child support claim was denied.

As the episode closes, the hosts underline the need for ethical codes within development teams. Guidelines alone aren’t enough; teams must establish practical escalation paths and support for developers who encounter ethical red flags. Developers should feel empowered to say no to unethical requests and escalate questionable requirements. Ethical responsibility, they stress, belongs to everyone involved—not just legal or compliance departments.

Ultimately, this episode calls for a shift in mindset. In an era where software often replaces human discretion, ethics must become a first-class concern in digital process design. Developers, architects, and analysts need to see themselves not just as implementers of logic, but as stewards of values that impact real lives.

In the latest “Appian Rocks” podcast, host Stefan, Sandro, and Marcel discussed managing external data models in Appian. They focused on Data Transfer Objects (DTOs) for abstracting and transferring data between incompatible systems. Marcel, a solution architect, highlighted the challenge of integrating external data, whether from microservices or legacy systems, and questioned forcing a single business object model across an enterprise.

The conversation explored communication methods and the common scenario of Appian performing internal data transformations. Stefan emphasized that Appian often needs only a subset of external data. Marcel explained that a central translation layer for DTOs could consolidate logic, preventing widespread changes if a DTO evolves. They also mentioned API composition and anti-corruption layers (ACLs), which facilitate communication between systems using their own data models, with translation in the middle. Marcel likened DTOs to “DHL packages” for data, while ACLs help reduce transferred information, adhering to the “need-to-know” principle.

Stefan pointed out the fundamental difference between process-driven Appian systems and data-storing backends. Marcel added that highly normalized external data might require denormalization for Appian UI performance. They also covered various forms of coupling, including data format, interaction style, semantics, order of operations, network location, temporal coupling, and network topology. Stefan shared an anecdote about time zone issues causing data discrepancies.

Sandro presented a “war story” about enriching read-only external customer data. Stefan immediately suggested Appian’s sync records as a solution for creating cached local copies and enhancing query speed. Marcel agreed, comparing it to a materialized view. When Sandro revealed that API-based integrations across multiple unreliable source systems led to instability, Marcel proposed an API Composer service with caching and retry mechanisms. Stefan countered that Appian’s synced records can now handle unsuccessful or partial syncs.

They concluded that data duplication is a pragmatic approach, especially for low-priority reference data or when sensitive data shouldn’t reside directly in Appian. While reliable software is costly, local data duplication can be a cost-effective solution for individual applications. The crucial factor for data duplication is ensuring awareness of changes to keep the cached data current. Marcel, despite his skepticism, acknowledged that synced records effectively solve common problems in an approachable way, aligning with Appian’s platform philosophy.