1. Building An AppExchange
App
James Holmes
Force.com Architect
Atlanta • San Francisco

2. Agenda
• Intro
• Goals
• AppExchange Overview
• Building An App
• Packaging An App
• Upgrading An App
• Lessons Learned
• Conclusion

3. 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

4. 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

5. 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…

6. 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)

7. 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

8. 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)

9. 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)

10. 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

11. 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

12. Distributing An App
• AppExchange
for CRM
• TrialForce
otherwise

13. 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)

14. 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

15. 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

16. 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

17. 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

18. Lessons Learned
• Exception emails
• Sent anytime an exception occurs
• Very little context of problem to work with
• Setup a group email

19. Questions?
Thank you!
James Holmes
james@codescience.com