Skip to main content

Customization guidelines

To support your business requirements and processes, you can customize and extend the Medical Information 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 Medical Information Cloud, 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 the unexpected behaviors of stated features and functionalities, cause system errors, and 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:

  • Components not listed for access in Table 75, “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 approved for access in Table 75, “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 Medical Information Cloud components in customizations. This includes referring to Medical Information Cloud components in custom code on or off the platform and in declarative configurations, such as a formula field. For a list of exceptions to this rule, visit Table 75, “Component customization matrix”.

Component identification

You can differentiate Medical Information Cloud product components from non-product components by looking at their API names. The API names for all Medical Information Cloud components have a mvn__, mvn__MED_, or MED_ prefix. In addition, many Medical Information Cloud components have a banner on their detail page, which states that the component is part of a package.

Field that has a banner

To verify if a component is part of the Medical Information Cloud product, check whether the component is part of a Medical Information Cloud required package. To view a list of components for a package:

  1. In the Quick Find box in Setup, search for and select Installed Packages.

  2. Click the Package Name of the installed package. Komodo Health and Nintex are the publishers for all Medical Information Cloud required packages.

  3. 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 Medical Information Cloud components explicitly named in these sections: Edit and delete components. 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__, mvn__MED_, or MED_ 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__, mvn__MED_, or MED_, consult the parties responsible for implementing or altering Medical Information Cloud to prevent the cessation of any custom features or functionalities.

Edit and delete components

Table 75, “Component customization matrix” specifies the portions of the Medical Information Cloud product that you can modify.

  • 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.

Table 75. Component customization matrix

Type

Editable

Deletable

Referenceable

Permitted actions

Notes and exceptions

Apex

✓*

*Only the following items may be referenced:

  • MED_CMSIntfDefinition

  • MED_CMSService

  • MED_CMSSettingAccessor

  • MED_DCRCreateIntf

  • MED_E2B_MCCI_IN200100UV01_Batch

  • MED_MDMIntfDefinition

  • MED_MDMSettingAccessor

  • mvn namespaced code marked "global"

For the Apex classes listed under the Permitted actions column, you can only reference methods marked global in the code.

Examples:

Example 1. OKAY to reference because it starts with the word "global"

global MED_CMSResponse getDocuments (List<MED_CMSIntfDefinition.MED_Document> docs, String country)



Example 2. NOT okay to reference even though it is inside a whitelisted Apex class because it starts with "public", not "global":

public static List<MED_Fulfillment__c stampFulfillmentDefaults(List<MED_Fulfillment__c> fulfillments)



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.

  • MED_NewCase: Action Override only.

  • MED_WorkInstructions: Utility bar item only.

  • Do not use Aura components as sub-components in custom code.

Custom metadata types

 

 

  • Custom metadata type records may be created, edited, and deleted.

  • 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 records that have an 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.

  • Never edit a label's value.

Custom notification types

None

Custom objects

✓

  • 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:

  • MED_Test_Status__c

  • 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.

  • Formula field formulas may be modified.

  • Do not modify or reference Mock fields. Medical Information Cloud needs Mock fields for Apex unit tests.

  • Do not alter the formulas of fields listed in the mvn namespace.

Field sets

✓

✓

✓

  • Namespaced (mvn) fieldsets are not editable.

Flows

✓

List views

✓

✓

Lightning message channels

None

Lightning record pages

✓

✓

✓

  • Do not alter the MED_About Lightning record page.

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 namespaced (mvn) page layout.

Process builders

✓

✓

  • Salesforce has deprecated process builder; it is suggested to migrate to Flows. For more information visit Salesforce's documentation.

Permission sets

✓

  • Assign to users.

  • Include in permission set groups.

Permission set groups

✓

✓

✓

Picklist value sets

✓

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

✓

✓

✓

  • Do not alter the MED_TESTING_ROLE role.

Search layouts

✓

✓

✓

  • Do not alter the Default Layout search layout.

Sharing rules

✓

✓

✓

  • Do not alter sharing rules that reference the MED_TESTING_ROLE role.

SObjects

✓

✓

  • Fields may be added.

  • Field Audit History field selections may be modified.

Static resources

✓*

* Only the following items may be edited:

  • MED_Snapshot_Logo

  • MED_Snapshot_Style

Tabs

✓

Validation rules

✓

✓

✓

VisualForce components and pages

✓*

* Only the following items may be referenced:

  • MED_ChangeCaseOwner: page layout embedding only

  • MED_E2BGenerateSingle: page layout embedding only

  • MED_LiveChatInteractionLauncher: page layout embedding only

  • MED_NewCase can be URL addressed for use in CTI screen pops

  • Only listed pages can be referenced.

  • Do not reference VisualForce components.

Workflows

✓

  • Salesforce has deprecated workflows; it is suggested to migrate to Flows. For more information, visit Salesforce's documentation.



Required picklist values

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

Table 76. Required picklist values

Object / entity

Field name

Values

Notes

All

All

Do Not Delete

The value should be inactive.

Case

QA Reason

  • Ad Hoc

  • Automated

  • Targeted

Case

QA Status

  • N/A

  • Review Required

  • Review in Progress

  • Review Complete

Request Document

Delivery Option

  • Merge Into Package

  • Attach Separate, PDF

  • Attach Separate, Original Format

  • Verbal Only

  • Send as Link

While you cannot delete or edit any of these out-of-the-box values, you can add additional values.

Product

Status

  • Active

  • Inactive



Translation

Medical Information Cloud supports translation 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 through 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, Medical Information Cloud 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 Medical Information Cloud text that is displayed 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 Medical Information Cloud 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 Medical Information Cloud custom labels, visit Content management custom labels and Inquiry management custom labels.

Unit test considerations

Automated unit tests are a core component of the Salesforce platform upon which Medical Information Cloud resides. Medical Information Cloud ships with hundreds of unit tests that serve an important role in maintaining the overall quality of Medical Information Cloud in addition to helping ensure regressions do not occur over time. Therefore, as Medical Information Cloud 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 any customizations have not broken the Medical Information Cloud unit tests.

  • There must be at least two Person account record types.

  • The user running unit tests should be a System Administrator with the Bypass Validations custom permission. By default, this is given to the System Administrator profile.

  • There must be at least two available countries not including ‘ZZ’. All values must be available to all record types of all objects where it is used, except ‘ZZ'.

  • There must be at least two available languages. All values must be available to all record types of all objects where it is used.

  • The document folder with the API name MED_Dynamic_DDP_Documents must exist.

  • Restricted Picklists (Global Picklists or any picklist marked restricted) must have all values available to all record types.

  • When creating code or configurations that updates data or enforces restrictions (such as Validation Rules), add an exception to bypass the restriction or not update the data if the MED_Test_Status__c.MED_Is_Running_Tests__c and/or the mvn __Mavens_Test_Status__c.mvn__Is_Running_Tests__c custom setting is currently true. These fields are set to true when Medical Information Cloud unit tests are running (only in the testing context; it will never be set to true in production). This ensures that unit tests can pass reliably without restricting what business rules a customer implements.

To bypass Medical Information Cloud Content Management module 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 Medical Information Cloud Content Management system event service, so no system events are processed while your Apex unit tests run.