Once a Business Entity (Corporation, Government, etc.) have made the decision to adopt Salesforce as it’s CRM SaaS, Salesforce became a component of it’s IT landscape that needs to be configured, customized no matter , managed, and monitored. Most corporations would employ one or several Salesforce implementation partners to implement the configuration and customization of Salesforce to suite the different units in the organization needs, processes etc. The Cooperate IT and EA ( Enterprise Architecture) would need to control how the customizations and configurations are being implemented. Even if it is a one Salesforce partner is doing all the customization and implementation for the organization, you would be surprised to find that groups in this vendor do not completely adopt the same methodology, tools, not to mention naming conventions. The Enterprise Architecture team have to govern the Salesforce implementations and integrations with other IT systems on premises or cloud based). In this blog, I will go through what I learned while creating a Salesforce Governance Framework for a client.

How Many Salesforce Orgs Should I use?

A Salesforce Org is a deployment of Salesforce that has a defined set of licensed users. Your organization includes all your data and applications.

How many instance of Salesforce will you need for the cor2588poration? This is one of the most foundational and architecturally significant choices that must be made. This decision will impact all future Salesforce initiative and designs. To answer this question there are multiple things to consider:

The Enterprise Operating Model?

In Enterprise Architecture as Strategy (Ross et al.) the authors described an enterprise architecture operating model using the following 2×2 matrix where the axis are A) Business Process Integration and B) Business Process Standardization.

• Corporations high in the Unification and the Coordination quadrants should try to stick with as few orgs as possible. The high process integration requirements can be met with a web services integration strategy, however the potential value to the corporation is much higher in a single org. A proper governance strategy and an effective service delivery strategy are necessary to keep multiple Lines of Business’s (LOBs) happy while executing in parallel.
• Corporations in the Replication and the Diversification quadrants will probably always have multiple orgs. The work to consolidate different business processes and data models into one org is usually very complicated; plus it is very uncommon for the diversified business units to be accustomed to working in the same space as the other. However you should consider deploying a managed package from a central org into all of the replicated business units. That way you can provide local control/administration but maintain your pre-defined standard business processes.

Who is Paying for it?

Sometimes the architect is at the whim of those controlling the purse strings. If this is the case it is the architect’s job to make sure the company moves in the following direction:

• The Architect needs to have coordination and awareness of the entire Salesforce community in your company. This would be the precursor to setting up a Global Center of Excellence.
• Collaborate with the enterprise data architects to understand what data objects should or should not be in each org – and that each org is aware of any possible duplicated data objects. Data problems will be the death of Salesforce in your company.
• Push the Corporation toward setting up a Global Center of Excellence.
• Design and build a “Reference Architecture” that defines where and when an additional org is reasonable or necessary.

Multi-LOBs in one Org complexity?

Designing a Salesforce org to support an enterprise with many different LOBs is very complex. You need to enforce:

• Naming standards across your data model, configuration design, and custom code.
• The security design will be very complex. The design of profiles, permission sets, role hierarchy, sharing model, and public groups can be difficult to design, difficult to maintain, and especially difficult to refactor.
• The apex code design will need to be very mature to support a large enterprise model. Adhere to strict separation of concerns and a technical architect overseeing all aspects of the org.
• The data model will become much more complex and controversial as more LOBs are added to the org. Salesforce Data Architect should be responsible for managing the design and maintenance of the data model and participating in the Enterprise Data Strategy.

How to effectively manage multiple changes in a single org ?

Depending on the number of parallel work projects you may have difficulty supporting many initiatives at once. This is especially difficult unless you setup an effective governance model.

• CoE should oversees the business architecture and common standards of all Salesforce projects across your enterprise.
• CoE should participate in the design, review, and approve pf technical changes to the environment. This includes ALL configuration, the data model, and custom code.
• Each LOB solution should have its own tiered administration teams to enable the LOBs to make some changes by themselves without requiring central administration help.

How many LOBs can you support in one Org?

As the number of LOBs in the main org increases, typically the overhead will increase as well. The request backlogs will increase, the time to market decreases, and generally stakeholders become more anxious. This drives the business to want separate orgs. This, however, is NOT a good reason to split orgs. You can solve this with the following tactics:

• Setup a CoE to manage the stakeholders and articulate a clear roadmap of functionality releases across the LOBs.
• Tier your administration services allowing the LOBs to make their own changes through the use of delegated administration and a tiered data architecture.
• Charge back your support costs to the businesses by establishing a license tax. This will allow you to fund development and maintenance resources to support all the LOBs without the need for large capital efforts which would slow time to market. Different LOBs can pay a higher tax to have more dedicated resources focused on their backlog requests.
• You may have smaller LOB’s pooled around a CoE and centralized resources while your larger LOB’s fund and support their own org.

What are the regulatory, compliance, or security requirements?

In some industries, especially healthcare and financial services, there will be certain factors requiring you to setup a walled-areas:

• Personally Identifiable Information (PII) may have much different security requirements than other business data.
• Some LOBs have complex encryption requirements, IP restrictions, and confidential business data that create undue burden on the development and support team if those same requirements were placed upon all the LOBs.

Who will modify your org(s) and who will maintain your org(s)?

• If you have multiple development teams in the same org you will have a much higher level of overhead and governance than if each team was in a different org.
• If you decide to have multiple teams in the same org, you will need to build a robust environment management and release strategy.  Be prepared to employ a dedicated environment manager to handle the movement of code and metadata across the environments.
• There should be as few true system administrators in the org as possible.  Custom profiles and permission sets are critical to keep Roles & Responsibilities in check.
• Each LOB should have and maintain their own “Tier 0” support layer.  
• You should have a single service desk and entry point for all of your Salesforce support (Tier 1).  
• Each org would need its own Tier 2/3 support teams to troubleshoot issues.
• Multiple orgs will either all need their own release management process OR your existing release management process will become much more complex.

What is your integration strategy for business processes and data across multiple orgs?

Inevitably in a multi-org environment you will need to integrate across the orgs.  Salesforce makes this simple with Salesforce2Salesforce integration design.  Before too long you have a spaghetti of integrations, data replication, and very brittle point-to-point connections.

• Consider integrating through your Enterprise Service Bus. While this increases your integration timelines it will also keep you nicely decoupled.
• Consider a hub & spoke architecture in which one of your Salesforce orgs is setup with the master data that would be shared out to other orgs.
• Use managed packages to deploy functionality from your hub org to your spoke orgs.
• Use a reporting and/or collaboration hub where all all necessary data is pushed to a separate org for consolidated visibility.

Design, Development and Coding Standards

While often ignored, Design, Development and Coding standards are crucial to creating a consistent and readable codebase. This is extremely important when you are running multiple Salesforce projects in the same org, developed by different vendors or teams. Have you ever tried reading and understanding code on a large codebase that doesn’t follow coding standards? It can be quite a messy and unmaintainable process. You should adopt or write a coding standard that covers the following topics :

• Formatting and Style Conventions (Coding Style).             
  • Indentation.
  • Bracing.
  • Spacing.
  • Blank Lines.
  • Line Wrapping/Column Limit.
  • SOQL Queries.
• Naming Conventions (Declarative & Programmatic).
  • Declarative Development Naming Conventions.
    • Object/Field API.
    • Page Layouts.
    • Validation Rules.
    • Custom Settings.
    • Workflows.
    • Email Alert.
    • Outbound Messaging.
  • Programmatic Development Naming Conventions.
    • Apex Classes.
    • Methods.
    • Variables.
    • Visualforce Pages.
    • Controller Classes.
    • Service Classes (Business Logic).
    • Data Access Layer Classes (SOQL & DML).
    • Utility Classes.
    • Test Classes.
    • Apex Triggers.
• Declarative Programming/Configuration Standards.
  • Objects.
  • Fields.
  • Page Layouts.
  • Validation Rules               .
  • Workflows and Approval Processes.
  • Views, Reports and Dashboards.
  • Generic Configuration considerations.
• Code/Programming Documenting Guidelines.
  • Class Comments.
    • Visualforce Page Documentation.
  • Method Comments.
• Code/Programming Exception Handling.
  • Never Ignore Exceptions (unless you know what you are doing).
  • Specific Exceptions are not any better (at times).
  • Exception Message and Runtime Values.
• Code/Programming Organization.
  • Code Structure and Organization.
  • Controller Classes.
  • Service Classes (Business Logic).
  • Selector/DAL Classes (SOQL & DML).
  • Utility Classes.
  • Apex Triggers & Handler Classes.
• Force.com Coding Best Practices.
  • Test Classes.
  • Apex Coding Best Practices.
    • Bulkify your Code.
    • Avoid SOQL Queries inside FOR Loops.
    • Using Collections, Streamlining Queries, and Efficient for Loops.
    • Querying Large Data Sets.
    • Use of the Limits Apex Methods to Avoid Hitting Governor Limits.
    • Use @future appropriately.
    • Writing Test Methods to Verify Large Datasets.
    • Avoid Hard Coding IDs.
    • Best Practices for Designing Bulk Programs.
    • Apex Scheduling Best Practices.
    • Batch Apex Best Practices.
    • General Coding Best Practices.

When to use Configuration vs Customization

For Salesforce implementation to meet the various requirements and processes of your corporate various divisions, you will need to modify some of Salesforce out of the box behaviors and data objects and interduce new ones. You can accomplish this via:

• Declaratively using point &click tools that are available in the Setup menu and other stools such as Process Builder, Flow Builder, Workflow Rule, and Approval process.
• Install AppExchange Apps if there is an app published on the Salesforce AppExchange that meets the requirements with minimal declarative changes, it should be preferred to building a solution programmatically.
• Programmatically using coding skills and Salesforce programmatic tools such as Apex, Visualforce or custom lightning components to develop the solution. With this option, there is more control and flexibility but at a higher cost of building and maintaining the solution

Salesforce declarative tools are becoming more advanced which minimizes the need to always build a solution using programmatic tools. if a declarative tool can meet a requirement it should be preferred. If it is not possible to meet a requirement declaratively or through and AppExchange App then a programmatic solution should be used.

Logging, Auditing and Debugging

Useful logs provide the administrator or developer ( especially when someone has to debug/maintain someone else’s code ) with tremendous help when trying to understand what the code actually does. That is the diagnostic part of logging, the most important one and basically the one that developers could understand easier, as it is more part of their daily work routine. There is another part which is called audit logging. Where the diagnostic logging takes care of recording the events that happen during runtime ( method calls, input/outputs, HTTP calls, SQL executions ), the audit logging is responsible for recording more abstract, business logic events. Such events can be user actions (adding/editing/removal of content, transactions, access data) or other things that have either managerial value or, more importantly, legal value. In the back end world, there have been some great logging frameworks to choose from as the need for those arose a lot earlier. In the front end world, things haven’t gotten that far yet, but there are options that can help you do the extra mile ( and of course get rid of trivial console.log messages ).

Salesforce provides out of the box logging, auditing and debugging tools, such as :

• Salesforce Health Check: is a dashboard like page in setup that helps identify vulnerabilities in org security settings
• System Overview: is a page in setup that displays important information about the org such as usage of licenses, data and the limits for the org
• Storage Usage: display details of the org data and files usage and limits.
  • Data storage includes storage of objects like accounts, contracts , etc.
  • File storage includes files in attachments, and chatter files.
• Record Modification Fields: provides basic auditing information such as when an who created the record, when and who modified it last.
• Field History Tracking: Track changes to important record fields. There are restrictions on he number of fields that can be tracked.
• Field Audit Trail: Retain field history for key fields for a long time. Additional licensing is required.
• Setup Audit Trail: tracks setup configuration changes made by administrators or developers.
• Email Logs: monitors emails sent from Salesforce.
• Login History: verify login issues or check every login attempt.
• Login Forensics: identify unusual login behaviour.
• Debug Logs: Track errors in workflows, apex code, and system processes.
• Paused flows: paused flow interviews can be viewed in the process automation section.
• API usage notifications can be setup to send an email notification to the administrator. API usage requests can be viewed under the Monitoring section setup.

While Salesforce out of the box logging and auditing tools provide ample of resources to debug and audit any Salesforce implementation, The Organization IT department Operational Support, and the IT Security would have it’s own monitoring tools for monitoring the systems, and reporting on issues. You will need to implement integration that pushes some of Salesforce logs and audits to the appropriate organization tools or data marts.

Integration with Other Systems

No system is an island, in any Salesforce implementation, you will need to integrate Salesforce with the corporate ERP/Accounting system, among other systems. While you might have different departments, that would run different projects or implementations on Salesforce, all integration implementation with other systems should be managed centrally by the Salesforce Governance COE or integrations COE

Conclusion

Onboarding Salesforce into an organization’s IT landscape is no trivial matter. Establishing good governance of a Salesforce based implementation from the start, and good planning the onboarding process can smooth the implementation. There is no one Salesforce Governance model that would work for all organizations. You will need to build a customized governance model for your organization. This would require great knowledge of Salesforce, Enterprise Architecture, and your organization current IT Landscape and standards. Reach out to me if you need any help or guidance for implementing Salesforce and establishing a governance model and implementation standards that address your organization unique requirements and IT processes, and guarantee a successful Salesforce implementation.

Further Reading:

• Salesforce Developers Blog: Enterprise Architecture: Single-org versus Multi-org Strategy
• Coding Standards