Customization guidelines

To support your business requirements and processes, you can customize and extend the Komodo Publications Planning product. All customizations and extensions must be implemented following the prescribed tools, technologies, and functionalities described on this page. If you have questions on how best to alter the standard behavior of Komodo Publications Planning, visit How to Contact Customer Support.

Warning

Adhering to the guidance on this page ensures customizations and extensions remain functional and do not incur regressions as upgrades are shipped to the product over time. Failure to follow this guidance or altering the product’s behavior in a manner not explicitly defined on this page may result in unexpected behaviors of stated features and functionalities, cause system errors, or prevent the ability to upgrade the product to newer versions.

For information on supported product integrations, visit Integrations.

Customize product components

To ensure custom features and functionalities remain functional and do not incur regressions as upgrades are shipped to the product, follow these guidelines:

Do not edit or delete any Komodo Publications Planning component unless it is listed for access in Table 93, “Component customization matrix”. Components not listed for access in Table 93, “Component customization matrix” may be removed from the product at any point in time without advanced notice.
If you want to alter the functionality of components that are not listed for access in Table 93, “Component customization matrix”, such as custom buttons, create a copy of the existing component and make the desired alterations to the copied component.
In general, do not reference Komodo Publications Planning components in customizations. This includes referring to Komodo Publications Planning components in custom code on or off the platform and in declarative configurations, such as formula fields. For a list of exceptions to this rule, reference the Table 93, “Component customization matrix”.

Component identification

You can differentiate Komodo Publications Planning product components from non-product components by looking at their API names. The API names for all Komodo Publications Planning components have a mvn__ prefix. In addition, many Komodo Publications Planning components have a banner on their detail page that states that they are part of a package.

A sample banner from a custom Komodo Publications Planning object field. The banner says, "This Custom Field Definition is managed, meaning that you may only edit certain attributes."

To verify if a component is part of the Komodo Publications Planning product, check whether the component is part of a Komodo Publications Planning required package. To view a list of components for a package:

In the Quick Find box in Setup, search for and select Installed Packages.
Click the Package Name of the installed package. Komodo Health is the publisher for all Komodo Publications Planning required packages.
Click View Components. A list of components that are part of the installed package appears.

To prevent the cessation of any custom features or functionalities upon product upgrade, only edit, delete, and reference Komodo Publications Planning components explicitly named in the Edit and delete components section. Unless explicitly stated within a given component’s API name, label, description, or help text, any component whose API name is not prefixed with mvn__ is free of product concern. You may alter or remove these components without impacting out-of-the-box product behavior.

Note

This guidance is specific to out-of-the-box product behavior. Before making changes to components not prefixed with mvn__, consult the parties responsible for implementing or altering Komodo Publications Planning to prevent the cessation of any custom features or functionalities.

Edit and delete components

Table 93, “Component customization matrix” specifies the portions of the Komodo Publications Planning product that you can modify. The table contains these columns:

Type - the type of component.
Editable - indicates if you may make alterations to the component: yes (✓), no (empty), or yes but with exceptions (✓*).
Deletable - indicates if you may delete the component: yes (✓), no (empty), or yes but with exceptions (✓*).
Referenceable - indicates if it can be directly referenced in customer custom configuration: yes (✓), no (empty), or yes but with exceptions (✓*).
Permitted actions - specifies alterations to the component that are supported.
Notes and exceptions - specifies alterations to the component that are not supported.

For more information about editing components that are part of a managed package, visit Salesforce's documentation on Components Available in Managed Packages.

Table 93. Component customization matrix

Type	Editable	Deletable	Referenceable	Permitted actions	Notes and exceptions
Apex classes			✓*	* Only the following items may be referenced: `mvn` namespaced code marked "global" * Parser classes may only be used for the Field Mapping (`mvn__PP_Field_Mapping__mdt`) custom metadata type. PP_AbbreviatedDateParser PP_AbbreviatedDateTimeParser PP_MultiSelectParser PP_PercentParser PP_SerializedJSONParser
Apex trigger					Disabled triggers will be re-enabled during upgrades.
Apps			✓
Aura			✓*	* Only the following items may be referenced: Aura components may be embedded in Lightning App pages when they are available in the UI.	Do not use Aura components as sub-components in custom code.
Custom metadata types					Do not alter the definition or metadata of custom metadata objects. Custom metadata types should not be referenced by custom code as they might be restructured at any time.
Custom metadata type records	✓*	✓			Do not delete any custom metadata records that have a `mvn` namespace. These records can be temporarily edited but will be reverted on the next upgrade.
Custom labels			✓	Labels can be translated. Labels can be specified in configurations. Be sure to include any namespace using dot notation (e.g., `mvn.`).	Never edit a label's value.
Custom notification types
Custom objects			✓		This does not include custom metadata types or custom settings. Relabel via translation only.
Custom permissions			✓	May be added to profiles and permission sets.
Custom settings			✓*	* Only reference the custom settings listed below: mvn__Mavens_Test_Status__c	Read/reference the value in custom validation rules to make exceptions for testing. No other settings should be referenced.
Dashboards	✓	✓	✓
Dynamic document packages (DDPs)	✓	✓	✓
Email templates	✓	✓	✓
Fields	✓			Only picklist values may be modified. Permitted modifications to picklist values are listed in the "Picklist value sets" row of this table.	Do not modify or reference Mock fields. Komodo Publications Planning needs Mock fields for Apex unit tests. Do not alter the formulas of fields with the `mvn` namespace.
Field sets	✓	✓	c		`mvn` namespaced fieldsets are not editable.
Flows			✓	Flows marked as `Overridable` may be overwritten. For instructions, visit Salesforce's documentation.
List views	✓	✓
Lightning message channels
Lightning record pages	✓	✓	✓
Lightning record page assignments	✓	✓	✓	Lightning record pages must be assigned at the App level or below.	Do not set organization-wide sharing defaults for Lightning record pages.
Lightning Web Components			✓*	* Only the following items may be referenced: Lightning Web Components may be embedded in Lightning App pages when they are available in the UI.
Page layouts	✓	✓	✓		Do not alter the page layouts for custom metadata types or any `mvn` namespaced page layout.
Process builders		✓	✓		Salesforce has deprecated process builder; it is suggested to migrate to Flows. For more information, visit Salesforce's documentation on Workflow Rules & Process Builder End of Support.
Permission sets			✓	Permission sets can be assigned to users. Permission sets can be included in permission set groups.
Permission set groups	✓	✓	✓
Picklist value sets	✓			Picklist values can be removed unless listed in Table 94, “Required picklist values”. Picklist values that have a `Do Not Delete` label or that are listed in Table 94, “Required picklist values” may be deactivated. They must remain within the field configuration.	Do not delete picklist values that have a `Do Not Delete` label or that are listed in Table 94, “Required picklist values”.
Platform cache partition				Space can and should be allocated to the partitions.
Platform events			✓	Platform events can be fired or subscribed to.
Profiles	✓	✓	✓
Queues	✓	✓	✓
Quick actions and custom buttons			✓	Standard Salesforce record quick actions and custom buttons may be modified.	Do not alter quick actions and custom buttons that are part of a product package. Do not alter quick actions and custom buttons that reference Lightning components, Visualforce, or URLs.
Record types	✓		✓	The list of available picklist values may be modified. Default record types are editable.
Report types	✓	✓	✓
Reports	✓	✓	✓
Roles	✓	✓	✓
Search layouts	✓	✓	✓		Do not alter the `Default Layout` search layout.
Sharing rules	✓	✓	✓
SObjects	✓		✓	Fields may be added. Field Audit History field selections may be modified.
Static resources
Tabs			✓
Validation rules	✓*	✓	✓		Do not modify `mvn` namespaced validation rules.
Visualforce components and pages					Do not reference VisualForce components.
Workflows		✓			Salesforce has deprecated workflows; it is suggested to migrate to Flows. For more information, visit Salesforce's documentation on Workflow Rules & Process Builder End of Support.

Required picklist values

Table 94, “Required picklist values” lists values that exist within the product that may not be altered in any way.

Table 94. Required picklist values

Object / Entity	Field name	Values
Document Collaborator	Status	Pending Active Inactive
Plan Team Member	Status	Active Inactive
User Request	Status	Pending Complete
User Request	Result	Success Failed
Workflow Activity Service	SObject	Task

Translation

Komodo Publications Planning supports translations through the use of the Translation Workbench and custom labels. Package upgrades do not override translation configurations.

Translation Workbench

Translation Workbench is a standard Salesforce feature though which you can specify translation values for metadata and data labels, such as custom objects, fields, and picklist values. You may impart translation changes to any component supported within the Salesforce Translation Workbench, and based on the translated values in Translation Workbench, Komodo Publications Planning displays metadata and data labels in a user's language.

Custom labels

Custom labels are a standard Salesforce feature through which you can specify translation values for all Komodo Publications Planning text that display in the user interface.

You can also associate a custom label to custom metadata types that have the Custom Label API Name field. For example, if you want the Draft document state to be translated based on a user's language, you can create a custom label and add the custom label's name to the Custom Label API Name field on the CM_Draft document state record.

Keep these guidelines in mind when working with custom labels:

Never edit the base value. Only add language-specific translations.
Never reference Komodo Publications Planning custom labels in custom code or formulas. Custom labels could be deleted at any time if they are not used anymore in the product. For a list of Komodo Publications Planning custom labels, reference Custom labels (CM) and Custom labels (PP).

Unit test considerations

Automated unit tests are a core component of the Salesforce platform, upon which Komodo Publications Planning resides. Komodo Publications Planning ships with hundreds of unit tests that serve an important role in maintaining the overall quality of Komodo Publications Planning in addition to helping ensure regressions do not occur over time. Therefore, as Komodo Publications Planning is customized within a customer instance, all tests must pass regularly to ensure the system is behaving as expected and able to receive ongoing product updates and enhancements.

For unit tests to continue functioning properly, the following must be true:

Note

This list is not an exhaustive list of requirements. Adding validation rules or required fields can still break unit tests in some situations. Be sure to run all unit tests in your org before deploying to make sure that no customizations break the Komodo Publications Planning unit tests.

The user running unit tests should be assigned these permission sets:
- PP_Plan
- PP_Budget
- PP_Content_Author
- PP_Provision_External_Author
- PP_App_Permissions
Restricted picklists (i.e., global picklists or any picklist marked as restricted) must have all values available to all record types.

To bypass system events in unit tests that you write, use the CM_CustomMetadataGlobalTestFactory Apex utility class and the disableSystemEventService method, which has no arguments. This class mocks the Komodo Publications Planning system event service, so no system events are processed while your Apex unit tests run.

Administrative functions

Login history

As an administrator, you can view login history, download the last 6 months of login history, and potentially identify unauthorized access to the system. To access the login history, use the Quick Find box in Setup to search for and select Login History. Visit Monitor login history.

Enable Queueable Chaining

Currently, users cannot do real time processing or write real time triggers on the Document, Document Versions, or Task objects. This is due to Salesforce's CPU limits, which give processes a certain amount of time to be completed. If a process exceeds that time limit, an error occurs. The globally accessible Queueable Chaining Pattern solves this problem by ordering different jobs to be completed at different times.

Therefore, to customize the Document, Document Versions, or Task objects, implement the Queueable Chaining pattern. See the sample code below for an example of how to enable the Queueable Chaining pattern.

Enable the queueable class that extends the QueueableChainLink pattern using the following code:

public with sharing class CustomQueuable extends QueueableChainLink {
    private final String customVariable;

    public CustomQueuable(String customVariable) {
		// This super identifies the queueable name that will appear in the apex jobs
        super('CustomQueuable');
        this.customVariable = customVariable;
    }

   	// instead of an "execute" method which are used in queueables use this "executeLink" method which is custom to KPP's QueuableChain
    public override void executeLink() {
        try{
			/* insert custom logic here */
		}
        } catch (Exception queueableException) {
            */ throw an exception that you would like to see in the apex jobs should this queuable 
        }
    }
}

Then, schedule the job to run using the following code:

QueueableChainContext.enqueueJob(new CustomQueueable(customVariable));

Customization guidelines

Warning

Customize product components

Component identification

Note

Edit and delete components

Required picklist values

Translation

Translation Workbench

Custom labels

Unit test considerations

Note

Administrative functions

Login history

Enable Queueable Chaining

Search results