© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2022
L. Harding, L. BaylissSalesforce Platform Governance Methodhttps://doi.org/10.1007/978-1-4842-7404-0_12

12. Application Architecture (Phase A) Resource Base

Lee Harding1   and Lee Bayliss2
(1)
Clayton-le-Woods, UK
(2)
Clifton, UK
 

This chapter contains the resources required to govern Phase A of the Salesforce Platform Governance Method. These resources should be considered a starting point and can therefore be tailored to your exact requirements. However, we have made every effort to capture the main topics that have appeared throughout our Salesforce engagements and experience.

Tip

You do not need to use this resource base as a strict method or process. The idea is that this will give you a good indication of what you should be taking into consideration. The expectation is that you will use this as a guide and then build upon it as you navigate the Salesforce ecosystem.

Guidelines and Best Practices

This section contains the guidance and best practices that are available from Salesforce, as well as other resources that we have determined will be valuable. This section should serve to provide a good set of guidelines that can be reviewed by anyone delivering the governance function within your organization.

We know there is an infinite number of resources available on the Web, and although some are better than others, this resource base will provide you with a good selection of resources that we recommend. We do not intend to go into low-level detail for each item as, this book would be huge and weigh an absolute ton. So, we focus on pointing you to the detail or explaining the high-level concepts, expecting you to then follow up with additional reading where necessary.

General Architecture

As you should be aware by now, this resource base complements the context of the governance method described in Chapter 2, “Application Architecture.” To begin we have provided Table 12-1 to supply resource links to the content that’s discussed.

When we consider general architecture, we are referring to the building blocks that make your application run smoothly. We are concerned with the performance, since if the application doesn’t perform well your users will avoid using it. We also look at scalability, for as your user base grows the platform should scale with it. For capacity management, do you have enough resources available for the app to operate, and more important, have you considered the “cost” of growth over time?
Table 12-1

General Architecture Resource Links

Artifact

GitHub Ref

Description

Apex Code Best Practices: Force.​com Multi-Tenant Architecture

Multi-Tenant Architecture

Force.​com’s foundation is a metadata-driven software architecture that enables multi-tenant applications. This paper explains the technology that makes the Force.​com platform fast, scalable, and secure for any type of application while allowing multiple tenants or Salesforce instances to co-exist. This is an important foundational concept to understand and serves to explain why platform limits are such an important part of your design.

Data and File Storage Allocations

Storage Capacity

Capacity management is sometimes overlooked when governing a Salesforce implementation. Salesforce splits storage into two main areas: data storage and file storage. Both are calculated for you based on the org edition and the number of user licenses you purchase. Use this guide to understand what storage you will be provided based on the org capacity required. Understanding, how your application usage will grow over time will allow you to build your capacity plan. Pay attention to the edition, as this will certainly impact your allocated storage. Once you have a good idea of your growth (number of records over time by month, for example) you can plan ahead and include the cost of additional storage in your resource model. Using a spreadsheet to calculate your storage needs is a really good way to plan for any future financial outlay.

Lightning Console Technical Requirements

Lightning Console Performance

This is great place to start when considering where to begin with assessing Lightning performance requirements. This is an important factor of your Salesforce implementation. How the application will respond in a browser will set the scene for your end-user experience and could therefore affect user adoption. If your Octane score is within the prescribed limits, then you know that the JavaScript engine’s performance is running well. Also review EPT, Experienced Page Time, which measures the time it takes to download and load the entire contents of a Web page.

Salesforce Developer Limits and Allocations Quick Reference

Salesforce Limits

To ensure that the Salesforce platform can operate its multi-tenant environment, all transactions must have available resources in order to execute. The way this is governed is through the application of governor limits. These limits are in place to ensure that Salesforce transactions have access to the resources they need to execute—well, as long as you are within the limits defined in the platform. Limits are there to control resource availability for all the Salesforce applications vying for processing power.

Improve Inefficient Related Lists

Related List Performance

If you have detail pages that have a large number of related list records, you might be experiencing page load performance and usability issues. Read this article for suggestions on how to improve your pages and provide the right kind of related list information while being performant.

Declarative vs. Programmatic

Declarative vs. Programmatic

When thinking about your application and how to develop it, as a Salesforce Admin / Developer, you’ll be weighing using a declarative development option versus using code to build your application. Use this resource and the associated links to help you make this decision about the right way to go. It is possible to use declarative development options and build great apps without writing a single line of code. The emphasis is on having GUI-driven app creation that can be easily maintained and supported. The key decisions here will mainly center on the following:

Cost: If the app is developed using declarative methods, this should be far more cost efficient than using code.

Time: Time to build using declarative options is more advantageous than the code alternative.

Maintenance and Support: Using code to develop your applications will also mean that on-going support and maintenance may well require a certain skillset to further develop and resolve any related issues to the app over time. This can also impact costs for the same reasons. Do you have staff in your organization that can support this codebase, or will you need to go to market to bring these skills in?

Developer Beginner

Developer Beginner – Trailhead

Here you’ll find a broad introduction to many of the key concepts and features you’ll need to understand before you begin designing and architecting apps that leverage the unique power of the Force.​com cloud application development platform. (Welcome to Trailhead—we love this educational learning platform.) This is delivered as a “Trailmix,” a collection of individual trails that will give you a firm grasp of basic development and platform-specific learnings designed to get you creating fantastic applications on the Salesforce Force.​com platform.

Enterprise Architecture: Single-org versus Multi-org Strategy

Salesforce Org Strategy

Here is a fantastic resource to help you really delve into the question that every Salesforce professional will have to deal with at some point on their Salesforce journey: Should we use a single-org or multi-org strategy to serve our application needs? Use this resource to learn about the pros and cons of multi- vs. single-org Salesforce architectures. Use these detailed criteria to help you select your company's strategy. This is particularly useful where the environment already has multiple orgs and the requirement is to consolidate. It all comes down to fundamental topics that must be considered carefully. Cost is the obvious one. The more orgs you support, the more financial impact you are going to have. But aside from cost (and as the method suggests), the issues will be about the app requirements themselves and how the application architecture will enable co-existence, the use of a common data model, and also the use of a security model that’s not prohibitive against the original intent of the application’s use case.

Licenses Overview

Licenses Overview

This is a huge topic, but it’s at the heart of your Salesforce implementation. If you don’t consider the most appropriate license type to serve your requirements, you may find that you do not have access to the features and functionality that you need in order to be successful. For example, for Salesforce communities or Experience Cloud, if you have complex sharing and access requirements you will need to use customer community plus licenses over the standard customer community license. So, the lesson here is to enable specific Salesforce functionality for your users; you must choose the most appropriate user license for each user. To enable additional functionality, you can assign permission set licenses and feature licenses to your users or purchase usage-based entitlements for your organization.

Salesforce Features and Edition Allocations

Salesforce Features by Edition

There are many resources available that provide an overview of the Salesforce org limits. This reference provides a general overview of the limits for Salesforce features by edition. Keep this link in your favorites. It’s likely that you will need to refer to this regularly. There is an awful lot of detail to consider here, so take some time to review it, as it will undoubtedly reveal some interesting and relevant detail that you either hadn’t previously considered or were already acutely aware of.

Data Model – Object Relationship Overview

Object Relationships

When you are considering how data elements will relate to other data elements and therefore construct the overall Salesforce data model, look at this overview, which provides detail on all the relationship types that Salesforce has to offer. The object relationships in your data model will be a key part of your data model design. You need to decide if a lookup relationship will serve your needs, or perhaps a many-to-many relationship will be more appropriate; for example, you can use master–detail relationships to model many-to-many relationships between any two objects. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. This will all depend on the requirements and how the data will be represented in your model. Remember, it’s good practice to document your data model clearly and create a data model dictionary. This document will prove vital for good data model governance. Best practice would be to add clear descriptions for all objects and fields that you add. When other resources come to view the fields available in the model, they will understand the intention for creating the element and can decide if it suits their requirement or business purpose.

Considerations for Relationships

Considerations for Relationships

Now that you have a good understanding of the types of relationships on offer, review the following considerations before creating relationships between your objects.

Salesforce Naming Conventions

Naming Conventions

How to name your objects is all part of designing a data model that not only is fit for the purpose at hand but also follows a defined standard that’s enforced across your organization. Review this Salesforce Quip document, where you will find the recommended conventions for all Salesforce data elements from Apex classes and process builders to objects and fields.

Designing Dashboards and Reports for Force.​com Implementations with Large Data Volumes

Reports & Dashboards for LDV

This link provides an overview of how to design reports for large data volumes (LDVs). There’s a lot to consider here. Firstly, what is an LDV? Well, you would consider any org that has over 5 million records an LDV. So why is it important? If you have an LDV in your org then when it comes to reports and dashboards you have to consider how the data model is designed to provide optimal performance. We will cover this in more detail in the next phase, data architecture. Just be aware that if you expect your org to have millions of records across multiple objects and a complex relationship model, then creating performant reports and dashboards will be another key consideration.

Improve Report Performance: Best Practices

Improve Report Performance

Many factors can cause a report to perform poorly or to time out. The details in this link will provide a comprehensive guide for applying best practices for report performance. Concepts such as using efficient filtering, which controls how many records are returned, can increase report performance considerably.

Integration Patterns and Practices

Integration Patterns and Practices

This document describes strategies (in the form of patterns) for common integration scenarios. Each pattern describes the design and approach for a particular scenario rather than a specific implementation.

Salesforce Connect

Salesforce Connect

Salesforce Connect provides seamless integration of data across system boundaries by letting your users view, search, and modify data that’s stored outside your Salesforce org.

Localization / Global Deployments

In this section of the resource base, we focus on the resources available that cover design aspects for the end user; rather, how we ensure the Salesforce platform is accessible and useable for all end users, customers, and partners that will be using the solution.

To be successful, we need to focus on the aspect of the solution where language and currency influence application design. For example, if your solution will support multiple languages, how will you support every language from a UI and data model perspective? What can you do to make adoption of multiple languages and currencies a simpler task to achieve? The resources in this section should provide a useful reference and put you on the path to success (Table 12-2).
Table 12-2

Localization / Global Deployments Resource Links

Artifact

GitHub Ref

Description

Setting up the Translation Workbench

Translation Workbench

The translation workbench lets you specify the languages you want to translate, assign translators to languages, create translations for customizations you’ve made to your Salesforce organization, and override labels and translations from managed packages. You can also consider the use of custom labels to simplify how you reference translated text in code. You can then create reusable elements in your code that will always display the correct language of the user. This provides a very efficient way to present text in your application’s UI.

International Organizations: Using Multiple Currencies

Using Multiple Currencies

Review this guide if your solution will require the use of multiple currencies.

Workflow & Processes

Automation is what makes the Salesforce platform an extremely powerful application. There are many types of automation tools available with which you can turbo charge your application and business processes. Workflow rules, process builders, Salesforce Flow, triggers, and actions are all examples of automation tools that can be applied. The issue that you will have is deciding which automation tool is the most appropriate for the application that you are designing.

As with all automation tools there are pros and cons for each, and you will need to decide which will best serve the needs of your application. However, you need to be aware of not only what the automation method will provide, but also what the limitations and considerations are for each. And if you mix automation methods together, what does it mean over the longer term as the complexity of your environment increases? For example, if you have multiple applications or projects running in a single Salesforce org implementation, it would not be unreasonable to assume that each project could have a case object process builder to cover its individual project needs. Let’s also say that your projects have defined separate “before insert” triggers on the case objects as wellthings could get a bit messy.

Let’s consider this for a moment. Each project has a trigger component that fires the process builder when certain conditions are met. When you consider the Salesforce order of execution, you cannot guarantee the order in which the triggers will fire, which may impact any dependency that you have defined in a subsequent process builder, which could ultimately cause the business process to fail. Worse still, you could inadvertently create recursive behavior, which means that your automation logic performs badly and gives the application users a really bad experience.

So, best practices for automation should not be overlooked, nor should it be assumed that it will be taken care of by the platform. Time needs to be taken to consider the order of execution of your logic in the context of the business requirement you are trying to resolve. Best practices will dictate how to implement triggers properly with a trigger framework, and ideally there should be only one process builder per object.

Review the resources in Table 12-3 to make sure that you have all the information you need to design and define your automation solution.
Table 12-3

Localization / Global Deployments Resource Links

Artifact

GitHub Ref

Description

Which Automation Tool Do I Use

Which Automation Tool

Salesforce provides multiple tools to automate your organization’s repetitive business processes: approvals, process builders, workflows, and visual workflows

Process Automation Cheatsheet

Process Automation Cheatsheet

A process flow chart and comparative tables make it easy to figure out which tool is best for any particular use case.

Getting Started with Approval Processes: Approval Process Checklist

Approval Process Checklist

This resource provides a checklist for preparing the appropriate information before creating your approval process.

Automate Your Business Processes: Workflow Limits

Workflow Limits

This resource provides guidance on the limits that apply to rules that are applied to objects in the platform.

Cloud Flow Designer Guide

Cloud Flow Designer Guide

Before you begin building and distributing flows, understand the best practices in the Cloud Flow Designer Guide. In addition, when designing, managing, and running flows, consider the permissions, use limits, and data issues.

Extend Salesforce with Clicks, Not Code: Quick Actions

Quick Actions

Actions enable users to do more in Salesforce and in the Salesforce mobile app. For example, you can let users create or update records and log calls directly in their Chatter feed or from their mobile device.

Automate Your Business Processes: Process Builder

Process Builder

Many of the tasks you assign, emails you send, and other record updates are vital parts of your standard processes. Instead of doing this repetitive work manually, you can configure processes to do it automatically. Process Builder helps you automate your business processes and gives you a graphical representation as you build it.

Automate Your Business Processes: Process, Limits, and Considerations

Process, Limits, and Considerations

Before you start creating, managing, and activating processes, understand the limits and considerations.

Formulas

Use formulas to take values from fields in either your custom or standard objects to perform a calculation or execute defined logic to automatically populate a field. There are formula field data types that we can define, and there are numerous data elements that we can use in logic to ensure that the data returned is the data that we expect. We can also use formula fields (via cross-object formulas) to reference data that reside in other objects. Cross-object formulas could be up to 10 relationships away. However, careful attention must be given so as to ensure that you are not presenting data to users to which they would otherwise not have access.

Review the following table to find all the resources that cover formula fields, including where and how we use them.
Table 12-4

Localization / Global Deployments Resource Links

Artifact

GitHub Ref

Description

Extend Salesforce with Clicks, Not Code: Calculate Field Values with Formulas

Calculate Field Values with Formulas

Formula fields are a great way to derive a field value by performing a calculation from other fields in an object. This resource explains how they work.

Formulas Cheatsheet

Formulas Cheatsheet

Use this resource to quickly see what operators, expressions, and functions you can use with formula fields.

Extend Salesforce with Clicks, Not Code: Common Formula Errors

Common Formula Errors

Review common errors that can occur with formulas and learn how to fix them.

Extend Salesforce with Clicks, Not Code: Tips for Building Formulas

Tips for Building Formulas

This resource provides many tips for building formula fields with a plethora of different use cases.

Files and Social

When we discussed the general architecture resources, we covered concepts related to the capacity planning aspect of your Salesforce solutions. In this resource, we provide more depth specific to the files aspect of your solution. Knowing the data requirements from a file storage perspective will ensure that you do not have unused expensive storage allocated to your org that you don’t need.

This resource base also covers the social aspect of your Salesforce solution. There are no guarantees that Salesforce will support social media platforms in the future, so make sure that before you implement any integration with a social media platform you use this resource to ensure that all considerations are understood.
Table 12-5

Localization / Global Deployments Resource Links

Artifact

GitHub Ref

Description

Differences Between Files, Salesforce CRM Content, Salesforce Knowledge, Documents, and Attachments

Differences Between Files, Knowledge, Documents, and Attachments

Explore the differences between various ways to manage your files and content. Using this resource, you will see all the various options and a clear description of the differences between them.

Set Up and Maintain Collaboration Tools: The Files Connect Setup Process

Files Connect Setup Process

The setup process for Files Connect differs for cloud-based and on-premises external data sources.

Sales Productivity: Guidelines for Using Social Accounts, Contacts, and Leads

Guidelines for Using Social

Review guidelines for using social accounts, contacts, and leads, including privacy and security details and which social networks are available by record and user experience.

Phase A Standards

General

As much as possible, we want to ensure that your Salesforce org is self-documented. All description fields are required to be completed in line with the following description standards.

Aside from loop iterators such as i, j, and k, variable names, object names, class names, and method names should always be descriptive. Single-letter names are not acceptable. Object names should use CapitalizedCamelCase. Method or function names should use lowerCamelCase. Constants should be CAPITALIZED_WITH_UNDERSCORES.

Note

In fact, this is just an example of what is advised in the “Naming Conventions” link in Table 12-1.

Underscores should not be used for any variable name, object name, class name, or method name except as an application prefix. Overriding standard tabs, objects, and standard names should not be allowed without first seeking approval from your central governance team.

Names must be meaningful. Abbreviated names must be avoided; for example:

Good

Bad

computeAverage()

CompAvg()

boolean isError

boolean isNoError

Similarly, avoid the use of static variables wherever possible. Salesforce keywords cannot be used as class variables, and naming of individual metadata elements must conform to the following standards, including prefixes where specified.

Managed packages are not within the control of the individual project teams. Where a managed package is used it is expected that the use of the package is documented and approval has been sought from the central governance team.

Objects

Salesforce has three types of objects: standard, custom, and external. For our governance requirements, objects are further considered to be split into the following two categories:
  • Enterprise Object - Objects that are used by more than one business area; all Salesforce standard objects fall into this category. Any custom objects that are used across multiple business areas also fall into this category.

  • Project Object - Objects that are specific to a single project or business area; all custom objects initially fall into this category.

A central governance team will determine which entities are of which type during the engagement via regular architectural reviews. Creation of and/or changes to project objects are permitted by the project team only.

The central governance team may promote project objects to enterprise objects.

Changes may not be made to enterprise objects without the agreement of the central governance team.

All Salesforce standard objects are enterprise objects.

Project objects may not duplicate existing enterprise objects.

Projects may not duplicate classes/approval processes/pages/etc. that function upon enterprise objects.

Projects that need to create/update functionality that interacts with enterprise objects are responsible for engaging with the central governance team for review and risk management.

The naming of project objects must have a unique prefix relating to the business area and project.

Descriptions

Description fields for all objects, fields, and other metadata should be populated where provided and must conform to the following:
  • Descriptions must be written in English.

  • Start with the business area and product acronym where they are used.

  • Include a useful contextual description that is meaningful for others reviewing this piece of metadata at a later date. Descriptions must be updated whenever the metadata changes or is used elsewhere.

Help

Help text for all objects, fields, and other metadata should be populated where provided and must conform to the following:
  • Descriptions must be written in English.

  • It must contain a useful contextual description that is meaningful for others reviewing this piece of metadata at a later date. Descriptions must be updated whenever the metadata changes or is used elsewhere.

Objects

Generally speaking, objects represent database tables that contain your organization’s information. For example, the central object in the Salesforce data model represents accountscompanies and organizations involved with your business, such as customers, partners, and competitors. The term record describes a particular occurrence of an object (such as a specific account like “IBM” or “United Airlines” that is represented by an Account object). A record is analogous to a row in a database table.

Objects already created for you by Salesforce are called standard objects. Objects you create in your organization are called custom objects . Objects you create that map to data stored outside your organization are called external objects .

Object names must start with a capital letter and may include a prefix as outlined here.

Enterprise Object

Format

Example

[ObjectName]__c

If your company manufactured guitars, you may want a customer object called Guitar__c.

Project Object

Format

Example

[BusinessArea][Project]_[ObjectName]__c

If your company has a business area called Sales and Marketing, and they have a project to develop a custom configuration on the Salesforce platform called Accelerate, your custom object might be called SMACC_Guitar__c where SM refers to “Sales and Marketing” while ACC refers to the project Accelerate.

[Project] is mandatory and must be populated; [BusinessArea] is optional and only needs populating if not limited to a single business area.

Note

The transition of a project object to an enterprise object must go through the central governance team given the potential impact on existing reports, sharing, workflows, and triggers. The promotion of a project object to an enterprise object WILL require effort.

Fields

Capture your unique business data by storing it in custom fields. When you create a custom field, you configure where you want it to appear and optionally control security at the field level.

Custom field names should have words delimited by an underscore. Whole words should be used, and the use of acronyms and abbreviations should be avoided. The API field name must meet the convention shown here.

Enterprise Fields (Global, Reusable)

Format

Example

[FieldName]__c

If a new field was created to define a guitar part, such as, Jazz Neck the example would look like Jazz_Neck

Project-Specific Fields

Format

Example

[BusinessArea][Project]_[FieldName]__c

Taking the example above further, SMACC_Jazz_Neck__c where SM refers to “Sales and Marketing” while ACC refers to the project Accelerate.

Note

[Project] is optional and only needs populating if not generic across all business areas.

Workflow

Workflow lets you automate standard internal procedures and processes to save time across your org. A workflow rule is the main container for a set of workflow instructions. These instructions can always be summed up in an if/then statement.

Names should be capitalized clear text, with the event clearly identifiable. The API name must meet the convention as follows.

Enterprise Workflows

Format

Example

[BusinessArea]_[WorkflowName]

Your Sales function may have a requirement to update customer details and therefore a good example could be SM_Update_Customer_Contact_Details.

Project-Specific Workflows

Format

Example

[BusinessArea][Project]_[WorkflowName]

Following on from the previous example, SM_ACC_Customer_Contact_Details.

Workflow field updates, email alerts, and so forth will follow the preceding naming convention.

Lightning Process Builder

Many of the tasks you assign, the emails you send, and other record updates you perform are vital parts of your standard processes. Instead of doing this repetitive work manually, you can configure processes to do it automatically. Process Builder helps you automate your business processes and gives you a graphical representation as you build it.

Names should be capitalized clear text, with the event clearly identifiable. The API name must meet the convention.

Enterprise Process Builders

Format

Example

[BusinessArea]_[ProcessBuilderName]

A good example might be SM_CASE_Rejection_Process. Notice that CASE has been added to clearly define the Object the Process Builder relates to.

Project-Specific Process Builders

Format

Example

[Business Area][Project]_[ProcessBuilderName]

With the Project added, SM_ACC_CASE_Rejection_Process.

Workflow field updates, email alerts, and so forth will follow the preceding naming convention.

Flows

Flows are the part of Lightning flow that collects data and performs actions in your Salesforce org or an external system. Lightning Flow provides two types of flow: screen flows and autolaunched flows.

Names should be capitalized clear text, with the event clearly identifiable. The API name must meet the convention.

Enterprise Flows

Format

Example

[BusinessArea]_[FlowName]

SM_Create_New_Service_Record.

Project-Specific Flows

Format

Example

[BusinessArea][Project]_[FlowName]

SM_ACC_Create_New_Service_Record.

Workflow field updates, email alerts, and so forth will follow the preceding naming convention.

Validation Rules

Validation rules verify that the data a user enters in a record meets the specified standards before the user can save the record. A validation rule can contain a formula or expression that evaluates the data in one or more fields and returns a value of “True” or “False.”

Names should be camel case, with the field and rule clearly identifiable. The API name must meet the convention.

Enterprise Validation Rules (Global, Reusable)

Format

Example

[BusinessArea]_[ValidationRuleName]

An example of a Validation Rule could be SM_Telephone_Number_Required.

Product-Specific Validations

Format

Example

[BusinessArea][Project]_[ValidationRuleName]

SM_ACC_Telephone_Number_Required.

Labels

Custom labels enable developers to create multilingual applications by automatically presenting information (for example, help text or error messages) in a user’s native language. Custom labels are custom text values that can be accessed from Apex classes, Visualforce pages, or Lightning components. The values can be translated into any language Salesforce supports.

Rather than name labels in relation to a business area or project, categories must be added to each label. There must be a category for the business to which it relates.

Format

Example

[Category]_LabelName

Survey_CustomerSurvey_Question_1.

Lightning Components

The Lightning component framework is a UI framework for developing single-page applications for mobile and desktop devices.

As of Spring 2019 (API version 45.0), you can build Lightning components using two programming models: the Lightning Web Components model, and the original Aura Components model. Lightning Web components are custom HTML elements built using HTML and modern JavaScript. Lightning Web components and Aura components can coexist and interoperate on a page.

The Lightning component should be named using camel case and Lightning Web Components as pascal case as shown here.

Format

Example

[BusinessArea][Project]_ComponentName

Lightning Components (Aura) AccountLookupCmp and for Lightning Web Components use accountLookupCmp where Cmp denotes a component.

Profiles

Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one.

As profile names are used by business users, to avoid confusion the business area will be used in full rather than the acronym.

Format

Example

[BusinessArea]ProfileName

For example, Sales and Marketing Community User

Permission Sets

A permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.

Where a Permission Set is specific to a Business Area

Format

Example

[BusinessArea]_PermissionSetName

An example API name for a Permission set is SM_Accounting_Approvals

Record Types

Record types let you offer different business processes, picklist values, and page layouts to different users. You might create record types to differentiate your regular sales deals from your professional services engagements, offering different picklist values for each. Or you might display different page layouts for your customer support cases versus your billing cases.

Format

Example

[BusinessArea]_[RecordTypeName]

For example, SM_Chat_live_Agent or Chat_Live_Agent where the Record Type is generic across the business.

Page Layouts

Page layouts control the layout and organization of buttons, fields, s-controls, Visualforce, custom links, and related lists on object record pages. They also help determine which fields are visible, read-only, and required. Use page layouts to customize the content of record pages for your users.

To avoid conflicts across multiple projects, or even if to begin with only one project exists within your Salesforce organization, it is good practice to name your page layouts according to the format shown here.

Format

Example

[BusinessArea]_[Object]

For example, Sales and Marketing_Account Layout

Roles

Salesforce offers a user role hierarchy that you can use with sharing settings to determine the levels of access that users have to your Salesforce org’s data. Roles within the hierarchy affect access to key components such as records and reports.

Format

Example

[BusinessArea] - Role Name

Sales - Regional Managers

Custom Settings

Custom settings are similar to custom objects in that they let you customize org data. Unlike custom objects, which have records based on them, custom settings let you utilize custom data sets across your org. Custom settings also let you distinguish particular users or profiles based on custom criteria.

Format

Example

[BusinessArea][Project]_CustomSetting

For example, SM_ACC_Billing_Data__c.

Static Resources

Static resources allow you to upload content that you can reference in a Visualforce page, including archives (such as .zip and .jar files), images, style sheets, JavaScript, and other files.

Format

Example

[BusinessArea][Project]_StaticResource

For example, SM_ACC_Billing_Data__c

Duplication Rules

A duplication rule defines what happens when a user views a record with duplicates or starts creating a duplicate record. Salesforce provides standard duplication rules for business and person accounts, contacts, and leads. You can also create duplication rules.

Format

Example

[BusinessArea][Project]_DuplicationRule

For example, Sales ACC Duplicate Contact Rule

Matching Rules

A matching rule defines how duplicate records are identified in duplication rules and duplicate jobs. Salesforce provides standard matching rules for business and person accounts, contacts, and leads. You can also create custom matching rules.

Format

Example

[BusinessArea][Project]_MatchingRule

Sales ACC Matching Contact Rule

Checklists

The phase checklist simply tracks that each step and sub-step within the phase is governed correctly and completely. Each sub-step may have several subject areas to form complete coverage from a governance perspective.

Governance Step

Govern the General Architecture

Pass / Fail

Govern the solution for optimal performance, scalability, usability, and maintenance.

 

Govern the appropriate use of declarative and programmatic functionality used.

 

Govern the considerations for a single-org or dedicated org strategy.

 

Govern the usage of license types (capabilities and constraints).

 

Govern the data modeling concepts and implications of database design.

 

Govern the usage of reports and analytics (platform considerations and tradeoffs).

 

Govern the usage of external applications (Salesforce AppExchange and Application Integration).

 

Localization / Global Deployments

Pass/Fail

Govern the usage of the platform’s internationalization functionality (multiple currencies, translations and languages)

 

Govern the Use of Process Automation

Pass/Fail

Govern the use of workflow capabilities (rules, tasks, emails, field updates, and approvals) within the solution.

 

Govern the use of visual workflow taking into account the limitations and considerations of a visual workflow solution.

 

Govern the capabilities and limitations of Salesforce actions.

 

Govern the use of Lightning Process Builder, taking into account the limitations.

 

Govern the Use of Formulas

Pass/Fail

Govern the use of advanced formula features (VLOOKUP, roll-up summary, image, x-object), check against limitations.

 

Govern the use of hierarchical custom settings in a declarative solution.

 

Files and Social

Pass/Fail

Govern the application’s usage of files and content, including Chatter files, attachments, content, and knowledge.

 

Govern the integration with social capabilities of the platform.

 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.138.138