Customization guidelines
To support your business requirements and processes, you can customize and extend Scientific Publications Cloud 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 Scientific Publications Cloud product, 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 Scientific Publications Cloud product over time. Failure to follow this guidance or altering Scientific Publications Cloud 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 Scientific Publications Cloud 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 Scientific Publications Cloud product, follow these guidelines:
-
Do not edit or delete any Scientific Publications Cloud product component unless it is listed for access in Component customization matrix table. Components not listed for access in Component customization matrix table may be removed from Scientific Publications Cloud 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 Component customization matrix table, 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 components in customizations. This includes referring to 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 Component customization matrix table.
Component identification
You can differentiate product components from non-product components by
looking at their API names. The API names for all components have a
mvn__ prefix. In addition, many components have a banner on their
detail page that states that they are part of a package.

To verify if a component is part of Scientific Publications Cloud product, check whether the component is part of a 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. is the publisher for all 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 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 to prevent the cessation of any custom features or functionalities.
Edit and delete components
Component customization matrix table specifies the portions of Scientific Publications Cloud 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.
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. needs Mock fields for Apex unit tests. - Do not alter the formulas of fields with the mvn namespace. | ||
| Field sets | ✓ | ✓ | ✓ | - 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 Required picklist values table. - Picklist values that have a Do Not Delete label or that are listed in Required picklist values table 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 Required picklist values table. | ||
| 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
The following table lists values that exist within Scientific Publications Cloud product that may not be altered in any way.
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
Scientific Publications Cloud product 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, 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 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 custom labels in custom code or formulas. Custom labels could be deleted at any time if they are not used anymore in Scientific Publications Cloud product. For a list of 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 resides. ships with hundreds of unit tests that serve an important role in maintaining the overall quality of in addition to helping ensure regressions do not occur over time. Therefore, as 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 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 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));