We 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.
Discussion posts and replies are publicly visible
1) 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.
Thank 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?
An 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.
Thank 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.
We 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
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.