ArticlesUpdate Guidance: Non-Packaged Configurations Overview and Considerations

This article discusses:

• Definition of “managed”/”packaged”
• Definition of “un-managed”
• Examples of potential non-packaged/unmanaged Customization 
• Examples of Configuration
• How to identify non-packaged/unmanaged configurations
• What to consider when performing update testing if you have customizations
• Potential issues from customizations

New versions

Certinia offers SaaB (services as a business) solutions on the Salesforce platform. The solutions we implement come with pre-built, out of the box, managed functionality as well as some unmanaged components potentially (refer to “Accelerate” addendum at the end of this document). With this in mind, Salesforce has a myriad of its own tools that can be used to directly interact with Certinia functionality and objects. Each organization may use Salesforce tools to enhance what Certinia delivers out of the box. Below we have outlined the differences between packaged (managed) and unmanaged (not belonging to an installed package in the org) configurations/customizations in relation to our products. 

Within Certinia, configuration generally means performing the basic and expected setup steps to ensure that our solutions work as designed. customization, however, means the creation of new functionality tailored to your business needs - that does not exist as standard, after installing the managed Certinia packages. In some cases, both the combination of customization and configuration will be used to achieve the ultimate business requirements. The goal of this document is to provide administrators with a clear method to identify unmanaged components and what they should be aware of in relation to them. 

Definition of “managed”/”packaged”

A “managed” solution on the Salesforce platform comes in the form of a package (located under Setup > Installed Packages), where its components, processes and functionality are all managed by the package provider - in this case, Certinia. This means that the components delivered in the packages cannot be amended or changed. This is useful for shipping a wide range of functionality to many customers at scale.

Definition of “un-managed”

An “Unmanaged” component or package means the installer/creator can modify their components, such as fields, according to their requirements after the initial creation in the org directly. Compared to “managed” solutions, using fields as the example, the creator of the solution has control over the fields. If you wanted to make a field directly “required” on an object, you would not be able to directly make that change to the field itself. But if it’s unmanaged, then you can. In our context, “unmanaged” refers to components created outside of one of our packages. I.e an administrator creating a new field for a business use case - this would be unmanaged compared to a field delivered in one of our packages. 

Examples of potential non-packaged/unmanaged customization 

• Code based: 
  • Apex Classes
  • Apex Triggers
  • Visualforce pages
  • Third-party integrations
• Declarative: 
  • Flows
  • Approval Processes
  • Email templates/alerts
  • Process Builders 
  • Workflow Rules 
    • Retirement of Process Builders and Flows - details here
  • Custom fields
  • Validation rules

Examples of Configuration 

• Creation of records, new fields, picklist values, report types, permissions, page layouts, email templates
  • Professional Services Automation Examples:
    • Creation of Region/Practice/Group records, assigning Permission Controls, establishing Time Periods.
  • Accounting Examples:
    • Defining Chart of Accounts, Creating Years and Period, Configuring the import of FX Rates in Foundations.
  • PSA - Accounting Connector:
    • Setting up the synchronization of Region, Practice, Group and Project to Dimension 1, 2, 3 and 4. 
  • Foundations Message Types:
    • Creating a new message type to create Journals in Accounting from Expense Reports in PSA.

How to identify non-packaged/unmanaged configurations: 

• There are multiple ways by which you can identify customizations within your organization. Taking fields as an example, as standard, all our packages ship with a “Namespace Prefix'' value. This prefix can be a 1 to 15-character alphanumeric identifier that distinguishes our packages, components and their contents from packages of other vendors.
  • On an object, all API names of fields that belong to our packages will be prefixed with the namespace of the package it belongs to. I.e the prefix for the Accounting package is “c2g”, so any field with this prefix belongs to the package.
  • Managed package fields and other components can also be identified by the “” symbol in your org against the components. 
  • Any fields that contain the “__c” suffix and DO NOT have a prefix, are unmanaged fields. This could have been created by anyone with administrative privileges. 
  • Such fields would be unmanaged and thus not belong to one of our packaged solutions
  • Example prefixed fields below.
• As mentioned above under “Examples of customization”, there are various types and ways in which to customize the Salesforce platform - and specifically, the Certinia products, to meet your business needs. To understand if any customizations relate to Certinia products, you need to understand which objects are included in the Certinia packages. One way to do this is via the technical documentation here - under your products, locate the “Object Model” and this will list our objects and help you correlate them to any customizations you have below. 

Examples of how to trace customizations from within Salesforce

Note: no Flows, Process Builders or Workflow Rules are delivered in our managed solutions. The examples and steps below all help you find unmanaged solutions of the various platform tools.

• Custom Apex Triggers.
  • These are associated with sObjects. 
  • You can locate them via Setup > Apex Triggers. 
    • This will list ALL Apex Triggers within the org. Anything WITHOUT a Namespace Prefix is a custom, unmanaged, trigger not delivered by one of our managed solutions. 
    • To locate unmanaged triggers you can filter for anything where Namespace Prefix = null then check for any triggers associated with our objects.  
  • Alternatively, you can navigate to the object in question via Setup > Object Manager > Triggers. 
    • This will list ALL Apex Triggers against this object. Anything WITHOUT a Namespace Prefix is a custom, unmanaged, trigger not delivered by one of our managed solutions. 
• Custom Visualforce pages. 
  • You can locate them via Setup > Visualforce Pages.
    • This will list ALL Visualforce pages within the org. Anything WITHOUT a Namespace Prefix is a custom, unmanaged, visualforce page not delivered by one of our managed solutions. 
    • To locate unmanaged Visualforce Pages you can filter for anything where Namespace Prefix = null.
• Flows. 
  • You can locate them via Setup > Flows. 
    • This will list ALL Flows within the org. The “Package State” column will say either “Unmanaged” or “Managed-Installed”. Anything “Unmanaged” has been created outside of our packaged solutions and is not part of the managed packages. 
      • *Note: customers with the Accelerate build will have some unmanaged flows shipped by default. See addendum at the bottom of this document.  
    • It can be difficult to identify custom Flows related to our processes, generally checking the Flow name is a good place to start to see if it’s related to a Certinia process.
      • *Admins familiar with developer console debugging would also be able to identify flows being triggered in debug logs from Certinia processes executing. 
• Process Builders. 
  • You can locate them via Setup > Process Builders. 
    • This will list ALL Process Builders within the org. The “Object” column will list the object the process is related to. Anything with a Certinia object name will be an unmanaged process builder. 
• Workflow Rules. 
  • You can locate them via Setup > Workflow Rules. 
    • This will list ALL Workflow Rules within the org. The “Object” column will list the object the process is related to. Anything with a Certinia object name will be an unmanaged Workflow Rule. 
• Custom fields.
  • You can locate them via Setup > Object Manager > open the object you’re interested in > refer to the prefix analysis above. 
• Another option to the above examples would be to also review your original solution design documentation, if provided by your implementation consulting team. This will offer another avenue to explore to help you determine any customizations that may have been put in place during implementation.

What to consider when performing update testing if you have customizations:

Once you have identified customizations against our objects, it’s important that you document and understand what your customizations are doing - importantly, what their expected outcome is when they run, the typical record volumes they interact with is also important. For any standard Certinia process where customizations like the above touch our objects/processes, it’s vital those functional processes are tested to ensure your customizations work as expected post update. 

Potential issues from customizations

At Certinia, we thoroughly test the packaged solutions with each release. However, we cannot know how every customer’s unmanaged solutions interact with our code, objects, and processes within our managed packages. An example of a potential issue has been outlined below: 

Salesforce governor limits: 

• Each of the above customizations contribute to standard Salesforce governor limits whenever triggered. A common example is the CPU limit. Our triggers, classes and any customizations triggered by our processes executing will all contribute to the CPU usage within a transaction - which for synchronous processes is 10 seconds. 
• In a new release, we may add some code changes or enhancements that may potentially highlight inefficiencies in existing customizations. I.e where our code changes have now resulted in customizations breaching the CPU timeout limit - where previously they did not. 
• These customizations contribute to the standard governor limits on top of the Certinia processes doing the same.
  • Should such issues occur post update in sandbox, an investigation would need to be carried out to see what is causing the root of the problem. 

Addendum:

• “Accelerate” pre-configuration:
  • If within your org you notice unmanaged components with API Name prefixes of “FFX_”, these are related to an “Accelerate” build adopted in your org at implementation. 
  • This provides unmanaged components (Flows, Fields etc) within your org to accelerate the implementation of our solution based on common business requirements. 
  • Should any issues arise with these components post update, raise a case with our support team via the community.