Top Banner
Design Patterns Every ISV Needs to Know Andrey Volosevich Senior ISV Technical Evangelist @andreyvol Mac Anderson CTO, Fonteva @macscloud Ross Belmont Chief of UX, Appiphony @rossbelmont
19

Design Patterns Every Salesforce ISV Needs to Know

Aug 12, 2015

Download

Software

Ross Belmont
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Design Patterns Every Salesforce ISV Needs to Know

Design Patterns Every ISV Needs to KnowAndrey Volosevich

Senior ISV Technical Evangelist

@andreyvol

Mac Anderson

CTO, Fonteva

@macscloud

Ross Belmont

Chief of UX, Appiphony

@rossbelmont

Page 2: Design Patterns Every Salesforce ISV Needs to Know

Agenda: Design Patterns Every ISV Needs to Know

• Top Patterns in 2014

• Architecting Large Apps (Mac Anderson, Fonteva)

• Examples from other apps (Ross Belmont, Appiphony)

• Q & A

Page 3: Design Patterns Every Salesforce ISV Needs to Know

Ross BelmontChief of UX, Appiphony

@rossbelmont

Page 4: Design Patterns Every Salesforce ISV Needs to Know

Two Examples• Secure testing of external web services• Importing a diverse data set while architecting for flexibility

Page 5: Design Patterns Every Salesforce ISV Needs to Know

First Example

Page 6: Design Patterns Every Salesforce ISV Needs to Know

Different Endpoint for Testing

Page 7: Design Patterns Every Salesforce ISV Needs to Know

How Will the App Know the “Right” Endpoint?

Page 8: Design Patterns Every Salesforce ISV Needs to Know

Custom Code Populates a Protected Custom Setting

Page 9: Design Patterns Every Salesforce ISV Needs to Know

“Testing Flag” Alters the Custom Code’s Behavior

Page 10: Design Patterns Every Salesforce ISV Needs to Know

Benefits of This Approach• The app references the correct endpoint at the correct time• Only you (as the ISV) can specify the external endpoint

– If customers configured it themselves, there would be a support burden– No one can set the endpoint maliciously for a “man in the middle” attack

• Swapping the endpoints is simple (just install the extension package)• The extra “testing flag” object doesn’t pollute customer environments

Page 11: Design Patterns Every Salesforce ISV Needs to Know

Importing a Diverse Data SetArchitecting for flexibility to serve a broader customer base

Page 12: Design Patterns Every Salesforce ISV Needs to Know

External Web Service Creates a “Dossier”

Page 13: Design Patterns Every Salesforce ISV Needs to Know

• Creates different marketing campaigns targeted at alumni of specific universities

Different Types of Customers

• Drives marketing based on traditional demographic segmentation– Age– Gender

Page 14: Design Patterns Every Salesforce ISV Needs to Know

Contact and Dossier: Objects in the Org

Page 15: Design Patterns Every Salesforce ISV Needs to Know

Contact Looks Up to Dossier

Page 16: Design Patterns Every Salesforce ISV Needs to Know

Subscriber A Can Report on Age, Gender

Page 17: Design Patterns Every Salesforce ISV Needs to Know

Subscriber B Can Focus on Alumni Instead

Page 18: Design Patterns Every Salesforce ISV Needs to Know

Benefits of This Approach• Customers can add exactly what they want to the Contact record and layout, and nothing more

• Reporting is simplified by flattening down to the Contact record• A Dossier can be attached to Leads, etc. in the future• Easy to serve new marketing initiatives in the future

– Recent grads vs. 20 year alumni, for example (incorporating Age)

Page 19: Design Patterns Every Salesforce ISV Needs to Know