Collection of CTA summaries and decision guides

Posted byjohanngilibconsulting

This post is a collection of random, smaller summaries and decision guides for your CTA review board.

Table of Contents

Key Limits

1. Daily API Limits: Per Int. User: EE 1k, UE+PE: 5k, Cust. Plus + Partner: 200 Calls., Add-On Possible

2. File Storage: 10GB Base + 2 GB/ Internal License + 0 GB Extra for Ext. Users

3. Data Storage: 10GB Base + 20 (EE) OR 120 (UE,PE) per Internal User

4. Web-To-Case: 5k/Day

5. Web-To-Lead: 500 / Day

6. Sent Emails to Email addresses: External Email addresses: 5k / Day, Total  [internal + external] = 1000 x license up to 2M.

7. Streaming API Delivered Messages 24h: 25k EE / 50k PE+UE / Add-On: 100k

8. APEX Duration (Excl. API Call-Out) -> 120 Sec. Max. 10 Long Running concurrent Call-Out

9. User Rolles (Internal: /External: 10k/500k)

10. Sharing Rules: Standard Ownership:250, Criteria: 50 Per Object, Can be extended to ~1k

11. Rate Limits for Public Page (40 GB / 60 hours, 1,000,000 / Month)

12. Community Users (No limit but suggestion): Role Based 2 Mil, High Volume 10 Mil,

13. Ownership Based Data Skew: 10k

14. Bulk API per 24h: Calls 15,000, 10k per batch, 150 Mil. records

15. Max. entries per Assignment Rule: 3k 

16. Asynch APEX Execution 24h: 250k OR User * 200 (Which is lower)

17. Max DML operations per transaction: 150

18. Max SOQL queries per transaction: 100

19. Max CPU time per transaction: 10s

20. Max records processed in all DML operations per transaction: 10k

21. Max number of concurrent API call-ins with duration >20 sec: 25

22. Monthly API Limits based on usage-entitlement

23. Platform Event Publishing Limits: 250k per hour

24. Apex Heap (6MB sync / 12MB async),

25. View State sizes (170kb)

26. Login Rate Exceeded (3600/hour/user).

Large Data Volume

Record Limit on on-platform Objects

There’s no hard limit on records in Object. There are Orgs that get away with 100s of millions of records in an Object.

As said before, Data Storage can be a limiting factor.

The real limitation is performance.

Low Volume (< 1 Million)

-> No problem unless you have long-running transactions, Look-up or ownership skew.

Mitigation:

Avoid Skews and long-running transactions

Medium Volume (1 Mill. – ca. 20 Mill.)

As with Low volume

Additional:

Optimized Queries:

Optimize your queries and reports to be selective.

Create lean page layouts.

Custom Indexes:

Fields often used in SOQL queries or Reports

Skinny Table:

Create a skinny table (with SF Support) across standard and custom objects for an often used combinations of fields.

Archive & Purge

Only keep what you really, move everything else off-platform or into Big Object

Large Volume (20 Million – 100s of Millions)

As Low and Medium

Additional:

Make the object “dumb”.

Remove as much synchronous automation (Processbuilder, Workflows, Trigger, Validation Rules) from the Object.

Remove any Master-Detail relationships.

Org Strategy Decision Guide

Org Strategy decision guide

Are we having regulatory requirements to keep data, people or processes separate?

1. Yes -> Multi Org (Replication / Coordination / Unification/Diversification Strategy)

2. No -> Is there overlap between the data, people and processes between business units? Any added value by single org (e.g. 360 View)?

2.1. No -> Multi Org (Diversification Strategy)

2.2. Yes -> Are we exceeding SF limits and have no way to mitigate (e.g. Community Users > 10 Mil., LDV…)

2.2.1 No -> Single Org

2.2.2 Yes -> Multi Org (Replication / Coordination / Unification Strategy)

Multi Org Strategy implications:

1. People: Cross Org Users

-> Multiple Users with SSO between the Orgs

2. Data: Cross Org Data for reporting

-> Cross Org reporting with BI tool (e.g. Tableau CRM)

3. Process: Cross Org Processes (e.g. Global Accounts)

-> Integration Strategy (e.g MDM, ESB, Hub & Spoke)

-> Collaboration: Multi-Org Quip

4. Governance: Cross Org Governance

-> Global/Local CoE, Architecture blueprint, standards & guidelines

5. Development

-> Global base packages + local packages for adoption, Standardized CI/CD pipeline, Local & global support

Strategies:

1. Diversification

Independent Business units with no overlap

-> Provide economies of scale (e.g. Knowledge, best practices, CI/CD infrastructure)

2. Replication

Independent but similar business units

-> Provide standard infrastructure and components

3. Coordination

Unique business unites with overlapping processes

-> Share data/processes through interfaces & economies of scale (e.g. Knowledge, best practices, CI/CD infrastructure)

4. Unification

Single Business Unit with overlapping data and processes

-> Implement global standards + global data access (e.g. MDM, Customer 360…)

Strange Object Relationships

Salesforce has it’s share of strange object relationships. Here you find my personal summary. Let me know what I missed.

Controlled by Parent = CbP

Technically Look-up: Are shown as Look-up in Schema Builder

Account -> Contact

Parent Required: No

Technically Look-up

Sharing: Option for CbP AND Option inherited by Owner

Roll-Up: No

Account -> Opportunity

Parent Required: No

Technically Look-up

Sharing: Option inherited by Owner (but no CbP)

Roll-Up: Yes

Account -> Asset

Parent Required: No / Yes if CbP (Either Account OR Contact)

Technically Look-up

Sharing: Option for CbP

Roll-Up: No

Account -> Contract 

Parent Required: Yes

Technically Look-up

Sharing: Inherited from Account

Roll-Up: No

Account -> Case

Parent Required: No

Technically Look-up

Sharing: Optional implicit sharing via Account Owner (but no CbP)

Roll-Up: No

Account -> Order

Parent Required: Yes

Technically Look-up

Sharing: Option for CbP

Roll-Up: No

Account -> Task

Parent Required: No

Technically Look-up

Sharing: Option for CbP

Roll-Up: No

Opportunity -> Opportunity Product

Parent Required: Yes

Technically Look-up

Sharing: CbP

Roll-Up: Yes

Campaign -> Campaign Member

Parent Required: Yes

Technically Look-up

Sharing: Controlled by Parent OR Controlled by Lead/Contact

Roll-Up: Yes

Order -> Order Product

Parent Required: Yes

Technically Look-up

Sharing: CbP

Roll-Up: Yes

And my final list of true Master-Detail Relationships in the core Sales – and Service Cloud data model:

Account -> Entitlement

Opportunity -> Quote

Opportunity -> Opportunity Split

Quote -> Quote Line Item

Work Order -> Work Order Item

Service Contract -> Contract Line Item

Asset token flow summary

Situation:

I’ve  plan to have IoT devices which needs to make authorized calls to my IoT backend. The IoT backend in turn communicates with Salesforce.

IoT Devices are represented in Salesforce as Assets for Cases and alike. IoT owner/installer is a Salesforce User and uses a Custom Mobile App which can connect to the IoT device and obtain an Access token from Salesforce.

Requirement: IoT device must authenticate against the IoT backend.

Implementation:

IoT Backend is connected to Salesforce either directly or via ESB with Salesforce.

Salesforce acts as the Authorization server for the IoT device. Salesforce provides an Asset token and registers the device as an Asset in the Asset token flow.

 Asset token is used/behaves similar to the JWT bearer token flow. Asset token has additional information and can be used by “any” backend.

Once the Asset token is provided to the IoT device it can be used to communicate with the IoT backend in “autopilot” mode. The IoT backend verifies the Asset Token signature against the public key of Salesforce.

Advantage:

Salesforce acts as a trusted Auth Provider. IoT backend does not need to implement it’s own Auth. Server.

Downside:

Asset token can only be created by Salesforce User.

Implementation has to follow the Salesforce definition. 

Login Options:

  • Username + Password
  • Login Discovery (Community only)
  • Delegated Login (SOAP based against Identity Store)
  • Federated Login (SAML)
  • Social Login (OpenId Connect)
  • One time password via Email or SMS
  • Lightning Login (Internal only)
    • Replaces password with authenticator app (Google, Salesforce…)

Additional Login Topics:

  • Embedded Login
  • 2F Authentication
  • Login-Flow
  • Login as
  • frontdoor.jsp

Code Refactoring

My notes on Code Refactoring

Code refactoring is a business project, code refactoring has to serve a business goal. 

The goals of the refactoring have to be derived from the organizations goals. This might be expanding into new markets, greater flexibility in implementing new business models reduced maintenance effort or many other possibilities.

The defined goals might need a code refactoring to be achievable. Business needs to be part of the refactoring project as much as the Salesforce Team since you will need to ask a lot of questions.

1. Define Goal, Vision and future of Salesforce system

  • People: Who will be using the system? Who will be building and maintaining the system?
  • Processes: What will the system need to be doing? What are core processes, what are auxiliary processes?
  • Priorities: What should the system be optimized for: Easy maintenance, flexibility, performance, stability or …?

2. Asses current situation

  • What needs to be fixed, what works, what doesn’t work?
  • Focus first on broken and core processes. -> Business defines the priorities!

3. Define Architecture, Configuration and Coding guidelines

  • What needs to be built how?
  • Architecture guidelines -> Objects, System Landscapes, Click vs. Code, Integration Patterns, Event Architecture, Build vs. Buy…
  • Configuration guidelines-> Naming conventions, Record Type guidelines, Page Layout guidelines, Flow Building guidelines, Criteria styling, Feature flags…
  • Coding guidelines-> Trigger framework, naming convention, coding styles, coding rules & best practices, Synchronous vs. Asynchronous …

4. Deep dive assessment

For the identified core processes which need to be fixed identify:

  • What code/configuration can be removed since it’s unnecessary?
  • What needs to be moved to declarative (Flow, Validation rules, Page Layouts…) or vice versa?
  • What can be simplified, standardized or re-used?
  • What does not follow our coding guidelines?

Practical examples of coding guidelines:

  • One Method one job
  • Max Method / Class length
  • Custom Settings as feature flags
  • Variable naming convention activePartnerAccountList instead of AccountList
  • Move after insert record creation to Platform Event + Flow (if allowed by business)
  • Use trigger handler classes
  • Control trigger re-entry

5. Execution:

For everything that needs to be re-factored:

  • Define the expected business behavior (User Story, User Acceptance Criteria)
  • Write unit tests against user acceptance criteria
  • Refactor code 
  • Test and deploy

6. Asses outcome and learnings of refactoring

  • What worked? What didn’t work?
  • What did we learn along the way? Did we reach our goals?

Community Licenses Upgrades and availability

Community Licenses:

Change Community License without creating a new user

1. Customer -> Customer Community Plus = YES

2. Customer Plus -> Partner Community = NO

3. Partner -> Customer Community Plus = NO

4. Customer Community Plus -> Customer Community = NO

5. Customer Community -> Partner Community = YES

https://help.salesforce.com/articleView?id=networks_license_upgrade_eligible.htm&type=5

Mixed Licenses on same Account:

1. Partner Community + Customer Community Plus = YES

2. Customer Community Plus + Customer Community = YES

3. Partner Community + Customer Community = YES

Person Account:

1. Customer Community = YES

2. Customer Community Plus = YES

3. Partner Community = NO

How we run Mock CTA Exams

Participants:

Active: 3-4 Persons

Process

Preparation:

1.Participants agree on a common scenario a few days ahead

2. Participants agree on a 2h-3h time slot for the mock-review board a few days ahead

3. Everybody solves the scenario on it’s own time and speed ahead of the session

4. Judges and presenter are agreed on beforehand -> Builds real pressure for the presenter

Mock review board:

1. Presenter presents for exactly 45 Minutes, no feedback or comments from judges. Judges note down all questions, mistakes, unclarity…

2. After presentation 15 minutes break for presenter. Judges discuss questions and topics to be asked.

3. 30 – 45 Minutes Q&A. Round robin one question after another by each judge. One follow-up per question allowed

-> Judges try to give the presenter the chance to correct herself of correct any mistakes

-> There’s no right or wrong but often many solutions are correct (Does it work? Does it scale? Is it simple & elegant?)

4. Feedback from judges to presenter. Be strict but stay positive. 

What license to choose decision guide

Internal Users

  • Need access to CRM functionality
    • Need access to Sales Functionality (Quote, Sales Contracts…) -> Sales Cloud
    • Need access to Service Functionality (Omnichannel, Live Agent…) -> Service Cloud
    • Need Sales + Service Functionality -> Sales + Service Cloud
  • No need for CRM functionality
    • Needs only limited (10) custom objects -> Lightning Platform Starter
    • Needs many custom objects -> Lightning Platform Plus
  • Only needs chatter access -> Chatter Free
  • No Access to Salesforce besides Login (SF as IDP) -> Identity

External Users

  • Only Chatter Group access with no Branding -> Chatter external
  • Needs full CRM Sales Access (Lead, Opportunity, Quote…) -> Partner Community
  • Needs Self Service Support Access
    • Needs Ad-hoc Reports or Sharing or delegated external Admin -> Customer Community Plus
    • No need for Reporting or Advanced sharing -> Customer Community
  • No need to access Sales or Support Objects BUT many Cust. Objects -> External Apps
  • Limited Access to SF (10 Custom Objects, Chatter, Files) AND SF as IDP Login  -> External Identity

Email Integration: Einstein Activity Capture, Gmail/Outlook Integration and Lightning Sync

Einstein Activity Capture:

Synches Emails, Contacts and Events automatically into Salesforce (Contacts & Events both ways).

Can be used in conjunction with Gmail/Outlook Integration.

Emails are automatically attached to records.

Encryption:

Shield encryption is not supported.

Data is by default encrypted at Rest with 256 key.

Use Case:

Have transparency of your Sales Users Email communication with customers in Salesforce.

NOT: Data retention or audit requirements. Data is only stored for 6-24 months by default.

Supported Servers:

GMail, Office 365, Exchange

License:

Part of Sales Cloud (100 Users free)

Supported Objects:

Account, contact, contract, lead, opportunity, and quote

Storage

Emails are stored in AWS and can not be used in standard reports, automation or customization.

No data storage is consumed.

Setup:

Gmail: Admins prepare, Users have to connect there account

Microsoft: Admins prepare, Users

Can be shared with:

Nobody

Chatter Groups

Gmail/Outlook Integration:

Add-On to your Email client. See your Salesforce Data directly in Gmail or Outlook. Sync Emails back to Salesforce manually.

Can be used in conjunction with Einstein Activity Capture.

Emails are not automatically attached to records.

Use Cases:

Create Lead from Inbox

Update Opportunity from Inbox

Link Email to Case

NOT: Data retention or audit requirements. Data has to be attached manually.

Supported Systems:

Gmail: G Suite Gmail

Outlook: Microsoft Outlook & Exchange Server

Supported Objects

New record:

Accounts, Cases, Leads, Opportunities, and custom objects

Relate Emails:

Accounts, Opportunities and People, and custom objects

Setup:

Gmail:

Admin enables and defines pane.

User installs Add-On into Browser

Microsoft:

Server might need to be adopted.

Storage:

Emails are stored as Enhanced Emails in Salesforce.

Data storage is consumed.

License:

Free

Lightning Sync:

Irrelevant, Not available for new Orgs Winter ’21

GDPR Cheat-Sheet

PPT: https://trailblazers.salesforce.com/0694S000001AVYw

Change & Extend existing org implications

You have to change in an existing org. Org already has a Sales processes and you should add a service process.

Name risks and how to mitigate them?

My Thoughts:

  • Org Strategy: Delivery Risk -> Might need to set-up multi org strategy -> Early Assessment, adoption of timeline
  • Data Model/LDV/Storage/File Storage: Technical Risk: Might hit some limits -> LDV Strategies
  • License: Check if existing Budgets fulfill requirements and new License fulfills existing requirements
  • System Landscape: Delivery Risk: Existing tools might need to be replaced (e.g. Mailchimp -> SFMC) -> Asses and account for
  • Integrations: Dependency Risk: Existing Integrations might need  to be adopted -> Asses and account for
  • Identity: Technical Risk: Existing Identity Systems might need to be adopted
  • Governance: Personal Conflicts: Existing Teams must be integrated into planned Governance -> CoE….
  • Project Timelines: Delivery Risk: Unknown issues might arise during project -> Assessment of org beforehand, account for identified risks.
  • Testing: Delivery Risk, Existing functionality might break -> Identify high risk & impact functionality, implement regression testing (Manual & Automatic)
  • Budget: Additional License Cost, Extra Cost for Refactoring of existing Org
  • Sharing: Delivery Risk, existing Sharing concept might be to open and needs to be adopted -> Asses before project and account for
  • Business Automation: Existing Business automation might not be built to be scalable -> Asses and adopt if necessary (e.g. Trigger Framework, Refactoring, Governor Limits…)
  • Reporting & Analytics: Delivery Risk: Existing Reports might need to be adopted


HIPPA Summary

HIPAA:

Relevant for all data which is PHI & PII: Example: Johann (PII) has a broken leg (PHI).

PII: Personally Identifiable Information

PHI: Protected Health information

PHI relevant data has to be:

  1. Encrypted at rest
  2. Secured in transit
  3. Only accessed by people needing to access the data 

Implications:

1. Encrypted at rest:

PHI data needs to be encrypted at rest in all stages and systems.

  • Salesforce:
    • Shield Platform Encryption in SF
      • Not for Big Object / External Object
    • SF Standard field encryption -> Small number of PHI
      • Only certain custom fields
      • Not files
      • Can’t bring your own key

2. Secured in transit:

  • Mutual SSL on integrations (e.g. SF to ESB)
  • NOT: Emails (Cannot be encrypted unless specialized tool like Data Motion)
    • Ask cust. to log-in. 

3. Only accessed by people needing to access the data

-> Everything private, only open up what’s needed

Other implications:

  • Data masking in full copy sandbox needed to protect data from testers .
  • Anonymized/dummy data in Dev Sandboxes
  • Anonymized (global) reporting if necessary/possible

Two way SSL / Mutual authentication

Mutual Authentication:

Mutual authentication is a way to improve security by adding another layer. It helps prevent Client impersonation. Its (mostly) used for Server To Server communication.

Inbound:

Example: Mulesoft -> Salesforce

Needs to be enabled by SF support.

Certificate needs to be CA signed (Not 100% sure)

Steps:

0. Activate mutual Authentication by Salesforce Support

1. You upload a certificate to Certificate and Key Management “Upload Mutual Authentication Certificate”

2. Enable “Enforce SSL/TLS Mutual Authentication” via Profile or Permission Set for that API User

Whenever that API user makes a Request to Salesforce via the API (SOAP and REST) it needs to provide the Certificate and connect to a specified port (8443).

Outbound:

Example: Salesforce -> Mulesoft

Can be any certificate accepted by the target.

1. Upload a certificate to your Certificate and Key Management

2. Include the certificate in APEX Callout setClientCertificateName(‘DocSampleCert’);

You have to provide that certificate in every Call-Out.

Supports REST and SOAP Callouts, not sure about outbound messages and External Services.

Sales Order: A hidden champignon?

PPT: https://trailblazers.salesforce.com/0694S0000019WnR

Video: https://www.youtube.com/watch?v=bEd5M1Ntu2I&t=1s

Platform Event vs. Outbound Message
My personal decision guide:
If ESB allows PE/CDC & Volume manageable-> Event driven
If only SOAP available -> Outbound Message

Outbound message:

Advantages:
– Built in retry
– Sends session ID
– Built on SOAP
– No daily limit

Disadvantage:
– Can only be fields from record
– SOAP
– Only started from Workflows -> Workarounds might be necessary

Platform Events / CDC
Advantages:
– Payload can be freely defined
– Widely used standard “the future”
– PEs Can be sent from many places (Flows, PB, APEX, API)

Disadvantage:
– Daily/hourly limit
– No built in re-try -> Target system has to build re-try
– Not SOAP
– Does not send Session ID -> Target system must authenticate against SF in case of Callback