Shared Object Management Overview

Overview

This document provides guidance on what shared objects are, how to identify them, how to secure them and how to update them in a manner that is safe and responsible. When used with care, shared objects provide a layer of reusable components for the entire platform to fast forward the development of every application.

For example, a user sync module that pulls user information from Workday would fall into the first category, while an Engagement record will fall into the latter. Avoid objects with complex or specific business logic unless they apply to all referring applications and aren’t likely to differ between applications in the future. In general, the more well defined and structured the inputs and outputs of an object are, the easier it will be to reuse amongst different applications. The rules for which objects to place into a common objects application can differ from one organization to another, however it is important to consider the value the component will provide compared to the additional time to maintain, test, and coordinate among groups utilizing the object.

In some situations, having multiple common object applications, each specific to their scope, will make managing changes easier for those who utilize them. As an example, a department may have multiple applications to manage new product approvals, customer onboarding, and periodic customer review processes which share common data objects, expressions, and integrations. Some of those components may be specific to the department and others are used globally. For each common objects application that your organization decides to create, ensure the following are documented: 

• Description of the purpose and scope
• Owner or owning group 
• Implementation usage instructions 
• Who to notify when updates are made

Object Types

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

• Is the functionality going to be accessed by all platform users?
• Are other applications going to leverage the same functionality? e.g. vendor search?
• Is the functionality agnostic of the application it is in? e.g. a list of countries
• What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Once the team identifies the object(s), they should be moved to the appropriate application and renamed with the appropriate application prefix. Detailed descriptions for Appian objects are important to ensure that changes do not break the contract between the shared object and the corresponding dependent object. For expressions and interfaces, ensure common objects have test cases defined so that during updates, they can be tested for backwards compatibility. Rule inputs should also be given descriptions so that Designers can easily understand their intended use. Teams working on new applications should always consult the Common Objects applications in order to identify any functionality that could be reused. Proper naming conventions and descriptions will make these objects easier to search and discover. 

Security and Ownership

Since common objects are shared between different applications, changes to these objects can have a wide impact. Changes that benefit one app could potentially break another. Therefore, updates to common objects need to be taken with care after sufficient impact analysis.

In programs with multiple teams, we recommend securing the objects to a specific designer group (and revoking sys admin access from designers). In such situations, while all objects need to have an admin group defined (see Health Check for more details), common objects especially need to have correct security set up with one group as the object admins and other designer groups as viewers – so these objects can be used but not edited.

Common Object Use and Maintenance

Using a common object is very easy – just reference it in your application. Note that if the common object version you wish to utilize has not been deployed to your desired environment already, you may need to use a separate package to deploy it, if it is only part of the common object application but not your own.

When an object needs to be edited, make a change request to the owners. Where appropriate, consider notifying the impacted teams if the updates will result in changes to the end user behavior or will require consumers of the common objects to opt into the new functionality being developed. Who makes the change depends on your organization (see Example Process) but we recommend that owners delegate the edits to the change requestor (application team). Appropriate testing and reviews should occur before promoting to higher environments. An extra emphasis should be placed on regression testing to ensure the changes will be backwards compatible.

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

1. Request to make a change from the object owner(s).
2. Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
3. The owner grants edit access to the application(s).
4. If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
5. Owner revokes edit access to the application(s).