https://community.appian.com/discussions/en-USTelligent Community 12https://community.appian.com/discussions/f/user-interface/40553/reusable-components-appian/155129Mon, 13 Jul 2026 17:46:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:d0dd8a73-5a19-4aff-bb1d-07cc36f35977Mike SchmittA few of my favorites that I've come up with myself for my own use and use across my project: a datetime field in a side-by-side with an icon that gives the user a 1-click target to fill with the current date (or datetime) a file upload field that doubles as a read-only file preview field (predating the recent updates to the file upload field offering the "preview" pop-up) with a rich text icon saving the linked document ID into a local variable to show it within a preview field a universal preview field which detects the file type (PDF or image file) then opens it in the relevant on-form viewer, if possible, and defaults to a download link if incompatiblehttps://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-async/155128Mon, 13 Jul 2026 17:02:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:e17eab5f-518d-4016-86ad-5a19d18ee04bMike SchmittAnnoyingly, in doing this update they actually removed functionality that is no longer directly reproducible with the newer version - e.g. you could previously call a Start Process and determine exactly when it would return values to your interface by making use of intentional chaining and chain-breaking. Now instead it either wants to wait the *entire* process duration (regardless of any chaining or attendedness), or the *entire* 30-second timeout, or alternatively, be *entirely* asynchronous (providing zero process details returned, even though the async version currently stalls until chaining is broken in the called process, which i believe is a bug). I really wish they'd've given at least an alternate synchronicity option that reproduces the old behavior, because it was honestly quite a bit more flexible for some use cases.https://community.appian.com/discussions/f/rules/40544/ai-doc-center-vs-ai-skills/155127Mon, 13 Jul 2026 16:04:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:d185f39b-ee45-4986-89cb-7c0a5f9dfe7akl0001Hi Shubham, I can see input/output token usage for unstructured doc extraction ai skills and for doc center, but i don't see it for something like structured doc extraction ai skill. Do you know how I can view that?https://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloud/155126Mon, 13 Jul 2026 15:36:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:9442d524-c077-44db-aaf1-76a1b09de86aStefan HelzleWe only create a few folders: - Process models - Rules (Expressions, Interfaces, ...) - Documents: - Templates - Reports - Images We do this based on a checklist to have a clear baseline that extends what Appian provides by default. 1) We do not do that 2) Yes 3) Yes 4) Depends on your needs 5) There is no other option, so you will have to deal with the risks. 6) I do not see that. 7) I think that some standards are good, too many does not scale well. Keep it to a minimum and allow flexibility in the application.https://community.appian.com/discussions/f/data/40555/saving-one-to-many-relation-on-a-record-how-to-handle-the-items-that-must-be-deleted/155125Mon, 13 Jul 2026 15:26:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:587324a3-2784-4c41-9c1d-1a6c77ba6b3cStefan HelzleCorrect. You need to delete items manually.https://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloud/155124Mon, 13 Jul 2026 15:02:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:29d57435-9468-4ce4-ac7f-cda78928b507appianpram304724Thank you for the clarification. Based on your answers, we understand that an application is a container of object references, and that application security is applied only when an object is created. Existing object security is not automatically updated simply by adding the object to another application. As a related design and governance question, we are now considering how folders should be structured and secured within each application. Our current idea is to create separate folders for the main Appian object types used by each application, for example: * Interfaces * Process Models * Expression Rules * Record Types * Data Types * Constants We would then configure security on these folders using application-specific designer groups, so that developers assigned to one application can create and maintain objects only in the folders belonging to that application. We also noticed that Appian can automatically create default folders and groups when a new application is created, such as Rules and Process Model folders. Could you please advise on the recommended approach for the following? 1. Is it recommended to use the default folders and groups created by Appian, or to disable their creation and define a project-specific folder and group structure? 2. Is organizing folders by Appian object type a common and maintainable approach for large-scale or multi-vendor projects? 3. Is it appropriate to use folder security as the primary mechanism for controlling where developers can create and maintain objects? 4. Should security be configured on a parent folder and inherited by its subfolders, or should each object-type folder be secured individually? 5. Are there any limitations or risks when relying on folder security, such as objects being created outside the intended folders or security not being inherited as expected? 6. When a new object type is introduced later, is it reasonable for a central governance team to create the corresponding folders across all applications and apply the appropriate security? 7. Are there any recommended best practices for keeping folder structure and security consistent across multiple applications? Our intention is to define a common folder standard for all applications and to minimize accidental cross-application modifications by developers.https://community.appian.com/discussions/f/data/40555/saving-one-to-many-relation-on-a-record-how-to-handle-the-items-that-must-be-deletedMon, 13 Jul 2026 14:52:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:39b84c7c-41b4-40eb-82f4-5ec88e535956juliencIs there a best practice to handle a one-to-many relation in a record so that I can save and update the items selected from a multiple dropdown? (basically a use case where my object can have a list of related features, that can be changed). In https://docs.appian.com/suite/help/26.6/Multiple_Dropdown_Component.html#usage-considerations, I see that I can use a foreach to settle my data. But how do I say to Appian that it must remove the items that are not mentioned in the data I try to save? From what I am able to do right now, it is necessary to remove the unwanted items from the relation before inserting the new ones.recordssaverelationshipshttps://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-async/155123Mon, 13 Jul 2026 11:16:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:494de9c0-18b7-403a-9dd0-aa5fd5a55216Stefan HelzleSome insights here: https://appian.rocks/2024/12/09/appian-244-insights/https://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-async/155122Mon, 13 Jul 2026 11:15:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:96e5c6c8-6403-4d0e-890f-79fd3280344aStefan HelzleA1: Kind of. It really depends on chaining, process duration, number of nodes in the chain. A2: I can't tell. You will have to investigate each and every sub process.https://community.appian.com/discussions/f/process/40504/process-model-sub-processes-are-not-starting/155121Mon, 13 Jul 2026 10:10:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:9a6b81f8-36c2-49c4-98ec-fd96bc7131d2darians975647I absolutely enjoy this conversation! I was lately having trouble getting my sub-processes to trigger in Appian and felt I was losing my wits. It turned out that I had overlooked a simple setting! Thank you for sharing your solutions; learning from other people's experiences is quite beneficial.https://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-async/155120Mon, 13 Jul 2026 09:30:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:a21f6950-c5b6-473a-a4cb-92cd281781f1saisaran31Q1. So, my process model uses activity chaining all the way to the end. Given that my code uses `a!startProcess_24r3`, does this mean it works synchronously in this case?. Q2. I hope in my case when i change to new a! startProcess i need not to configure synchronous parameter to true right?https://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-async/155119Mon, 13 Jul 2026 09:07:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:bde7e622-3b33-4cc6-a96a-a11bcba3c4a9Stefan HelzleThe old version is async. But, you could use activity chaining to control when the call returns. This has changed with the new version. So, this is not just a one-one replacement.https://community.appian.com/discussions/f/appian-community-edition/40554/is-a-startprocess_24r3-sync-or-asyncMon, 13 Jul 2026 08:54:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:d5d69c2b-9736-4806-bd53-9a7f226705f9saisaran31Hi everyone, Could someone please let me know whether `a!startProcess_24r3` is synchronous or asynchronous? I am currently using this function in my code, but when I try to upgrade to the new `a!startProcess`, I see a "synchronous" parameter available. So, when I replace `a!startProcess_24r3` with `a!startProcess`, should I set "synchronous" to true or false?. Thanks in advancehttps://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloud/155118Mon, 13 Jul 2026 06:41:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:ec74bc9b-f85d-45b3-8d7c-854f384105c6Stefan HelzleAn application is only a container holding references to objects. The answer is: Only on creation. You also have to make sure that projects do NOT add shared objects to their applications. This would generate unnecessary dependencies and issues during deployment.https://community.appian.com/discussions/f/user-interface/40553/reusable-components-appianMon, 13 Jul 2026 06:25:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:af7f2e79-c06e-478a-90aa-0373fe89cf05khushim2428I'm planning to create some reusable components in Appian. I've already built several, including reusable forms, page headers, message banners, empty state (no data) screens, date and currency formatting utilities, and a few others. Can anyone suggest additional reusable components, patterns, or expression rules that would be useful across most Appian applications?https://community.appian.com/discussions/f/user-interface/40551/ai-icon/155117Mon, 13 Jul 2026 06:16:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:b17016db-1d9d-4511-9055-032608a2bd0ekhushim2428You can still add an AI icon in previous versions, for example:https://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloud/155116Mon, 13 Jul 2026 05:16:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:aa6131de-c182-468f-a0a4-665849aebc39appianpram304724Thank you for your response. Regarding answer 2, does application security automatically update or override the security of existing objects when they are added to an application, or does this apply only to objects newly created within the application using its default security groups?https://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloud/155115Sun, 12 Jul 2026 19:00:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:8f9a799a-9dc2-4c1b-af32-3b0f16e1a87eStefan Helzle1) Yes 2) Yes 4) Shared objects must be maintained by a separate group. 5) Each application has its own designers group which controls access to that app. 6) No 7) Keep your permission setup correct.https://community.appian.com/discussions/f/administration/40552/how-can-we-restrict-developers-to-editing-objects-within-specific-applications-in-appian-cloudSun, 12 Jul 2026 10:34:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:47008b7b-9a62-4520-baaf-d3e58bbf262aappianpram304724We are building a single Appian system, but we plan to divide it into multiple applications based on responsibilities and business domains. For example: ・Application A ・Application B ・Business Common Application ・Common Components Application ・Administration Application Our environment is Appian Cloud, not an on-premises installation. Multiple development teams and vendors will work in the same Appian development environment. To prevent developers from unintentionally modifying objects owned by another team, we would like to control which applications each developer account is allowed to develop. Our expected behavior is: ・Developers assigned to Application A can create and modify objects belonging to Application A. ・They can reference shared objects from the Common Application when necessary. ・They cannot modify objects belonging to Application B or other applications. ・Developers assigned to Application B should have the same restrictions for Application B. ・System administrators may modify all applications and objects. We are considering creating separate developer groups for each application and configuring application and object security. Could you please advise on the recommended approach for implementing this type of design-time access control in Appian Cloud? In particular, we would like to confirm the following: 1. Can developer permissions be controlled at the application level? 2. Does application security automatically apply to all objects contained in the application? 3. If not, must security be configured individually for each Appian object, such as Interfaces, Process Models, Record Types, and Expression Rules? 4. How should security be managed for shared objects that need to be referenced by multiple applications but modified only by the common development team? 5. Is there a recommended group and security structure for a multi-team or multi-vendor development environment? 6. Are there any limitations where a developer can still modify an object through another application or by directly opening the object? 7. What is the recommended way to prevent accidental cross-application modifications? We understand that an Appian object may be included in multiple applications. Therefore, we would also like to know whether security should be enforced based on individual object security rather than application membership. Our main objective is not runtime access control for end users. We want to restrict design-time development access for developer accounts and clearly separate ownership and modification responsibilities for Appian objects between development teams.SecuritypermissionApplicationSecurity GroupobjectCloudhttps://community.appian.com/discussions/f/data/40545/record-view-performance/155114Sat, 11 Jul 2026 09:40:00 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:f7f57ae4-9e7b-48e9-b617-315cd8a09311Stefan HelzleShubham Aware already pointed out the issues around rv!record. My approach is to just pass the record identifier and query any required data in the interface. This allows more control over what and when data is actually loaded.