building an app exchange app

Building An AppExchange AppJames HolmesForce.com Architect

Atlanta • San Francisco

Agenda

• Intro

• Goals

• AppExchange Overview

• Building An App

• Packaging An App

• Upgrading An App

• Lessons Learned

• Conclusion

About Me

• From Java to Salesforce

• 3 years of intensive Salesforce.com development

• Salesforce Certified Developer

• 4 AppExchange Apps completed, with more underway• Skoodat

• Constant Contact for Salesforce

• Glance for Salesforce

• BlueHornet for Salesforce

Goals

• A balanced presentation with equal interest for business people and technical people

• Overview of what an App is

• Details about the steps that go into building and

packaging an App

• Share lessons learned and best practices

• Limitations and workarounds

AppExchange Overview

• What is the AppExchange?• Distribution platform for Apps• Both free and fee-based Apps

• App Availability

Edition Apps Notes

Contact Manager 1 Can’t actually install an App apparently

Group 1 Limited functionality and problematic to

target Apps for

Professional 5 Limited functionality and problematic to

target Apps for

Enterprise 10 The first real org that can accept all Apps

Unlimited Unlimited The sky’s the limit…

3 Primary Types of Apps

• Integration• Sync data between systems• Examples: Constant Contact for Salesforce, Glance for Salesforce

• Augmented Functionality• Add features and functionality to Salesforce• Examples: EchoSign, MyFax, GeoPointe (Google Maps for Salesforce)

• Platform Solutions• Provide independent business applications• Examples: Skoodat, ServiceMax (field service), DreamTeam Project

Management, FinancialForce (accounting)

What Is An App?

• In a nutshell: a deployable grouping of config and code

• Data model customizations• Additional objects, fields, validation rules

• User Interface customizations• Additional page layouts, tabs, VisualForce pages & components

• Custom Code• Apex classes & triggers

• Workflow

• Reports & Dashboards

Building An App

• Setting up a development org

• Developer (anyone, free)

• Partner Developer (super-sized, requires

registration)

• Develop the App components

• Creating a package

• Managed vs. Unmanaged

• Selecting a namespace (e.g., G4S = Glance for

Salesforce)

Managed vs. Unmanaged

• Managed

• IP protection (no source code)

• Support for upgrades (push patches)

• LMA (License Management & Administration)

• Setup trials

• Track installs and licenses

• Extend, activate, suspend and expire licenses

• Aloha compatibility (Group & Professional)

Managed vs. Unmanaged

• Unmanaged

• Limited to certain editions (no Group /

Professional)

• Source code visible

• Good for distributing open source code as an

installable, cohesive unit

• Several free available from Salesforce and others

• Lead Scoring

• Many “starter” and “example” Apps for new or advanced

features

Packaging An App

• Beta Package

• Can test before releasing

• Still able to add / subtract objects, fields, code, etc.

• Security Review

• Run security scanner first

• Only scans code in package

• XSS (Cross Site Scripting)

• Publishing to the AppExchange

• Release package

Distributing An App

• AppExchangefor CRM

• TrialForceotherwise

Upgrading An App

• Major vs. minor upgrade

• Minor• Edits to existing code (Apex, VisualForce)

• Cannot add objects or fields

• Creating a patch org

• Push upgrade

• Major• Can change anything

• Can’t remove objects, fields, classes, triggers (just deprecate)

Lessons Learned

• Not all org editions have the same features

• Standard object availability

• Chatter availability

• Exposing web services

• Primarily have to worry about Group and

Professional

Lessons Learned

• Governor limits

• Optimize APIs for syncing data

• Beware of number of requests

• Beware of payload sizes

• Beware of executed scripts to parse data

• Utilize batch and scheduled jobs

• Create custom objects to stage data

• Chain batch jobs to process large volumes of data

on different objects

Lessons Learned

• Beware of required fields and custom validations

• Code defensively for all inserts / updates to

standard objects

• Can perform check during install and warn

Lessons Learned

• Keep the interface native

• Less jarring for users

• More seamless experience

• Familiar navigation and UI idioms

• Refrain from custom UI widgets and graphics

that don’t match Salesforce

Lessons Learned

• Exception emails

• Sent anytime an exception occurs

• Very little context of problem to work with

• Setup a group email

Questions?

Thank you!

James Holmesjames@codescience.com