Building Custom Functionality in ServiceMax
The picture below outlines the flow of building custom functionality in a Sandbox instance and deploying it to the production instance:
In order to implement your customizations in a scalable way, it is strongly recommended to adhere to the following guidelines:
• Identify the closest standard module in ServiceMax where this requirement would fit. Create new modules only if none of the standard modules match with your requirement. For example, if the requirement is about capturing billing schedule of a service contract, attach the functionality to the Service Contract module in ServiceMax.
• Identify the standard submodule in ServiceMax where this requirement would fit. If your functionality is similar to one of the existing submodules but slightly different, simply use the existing Submodule ID. Each submodule has its own set of standard settings and tags that you may be able to take advantage of. If the functionality is not supported in any submodule, you can create a new custom submodule.
• Identify all the configurable parameters you like to have. While this is a subjective exercise, a good rule of thumb is to avoid any hard-coding in your code. If you need to provide flexibility either during development or you anticipate end users might change their requirements, it is a good opportunity to make the behavior driven by configurable parameters. Any future coding effort can be avoided by this.
• For each configurable parameter, determine the scope of its impact—org-wide or not. Org-wide (Global) settings impact functionality for all users regardless of their login or profile.
• If your functionality requires new records to be created from existing records, make it configurable using the Object maps in ServiceMax configuration. This provides complete scalability and flexibility for the customer admin to configure the field mapping between the source and target objects.
• Build the functionality using ServiceMax settings and object maps. See sample code in ServiceMax API.
• If the code is written in Apex, create unit test cases. While Force.com accepts 75% code coverage, target at least 90% to 95% coverage of your code. This ensures successful migration to production. Avoid hard-coding references data in unit test cases. Since the test cases will fail if data is missing, create any/all data dynamically in unit test cases.
• Before you can deploy the functionality in production, you must create the custom modules, submodules, settings, object maps, and so on, in production first. This is an important step and must be done manually in production using ServiceMax Configuration screens. See Configuring ServiceMax for details.
• After creating your meta-data in production, adjust the setting values appropriately in all existing ServiceMax Configuration profiles. Note that when a new setting is created, it is automatically linked to appropriate profiles with its default value.
• Create an unmanaged package of your customizations and deploy to production. While packaging is not mandatory in Force.com, it is a recommended best practice.