Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Building An AppExchangeAppJames HolmesForce.com Architect                      Atlanta • San Francisco
Agenda•   Intro•   Goals•   AppExchange Overview•   Building An App•   Packaging An App•   Upgrading An App•   Lessons Lea...
About Me•   From Java to Salesforce•   3 years of intensive Salesforce.com development•   Salesforce Certified Developer• ...
Goals• A balanced presentation with equal interest for  business people and technical people  • Overview of what an App is...
AppExchange Overview• What is the AppExchange?  •    Distribution platform for Apps  •    Both free and fee-based Apps• Ap...
3 Primary Types of Apps•   Integration    •   Sync data between systems    •   Examples: Constant Contact for Salesforce, ...
What Is An App?•   In a nutshell: a deployable grouping of config and code•   Data model customizations    •   Additional ...
Building An App• Setting up a development org  • Developer (anyone, free)  • Partner Developer (super-sized, requires    r...
Managed vs. Unmanaged• Managed • IP protection (no source code) • Support for upgrades (push patches) • LMA (License Manag...
Managed vs. Unmanaged• Unmanaged • Limited to certain editions (no Group /   Professional) • Source code visible • Good fo...
Packaging An App• Beta Package  • Can test before releasing  • Still able to add / subtract objects, fields, code, etc.• S...
Distributing An App• AppExchange  for CRM• TrialForce  otherwise
Upgrading An App•   Major vs. minor upgrade•   Minor    •   Edits to existing code (Apex, VisualForce)    •   Cannot add o...
Lessons Learned• Not all org editions have the same features  •   Standard object availability  •   Chatter availability  ...
Lessons Learned• Governor limits  • Optimize APIs for syncing data    •   Beware of number of requests    •   Beware of pa...
Lessons Learned• Beware of required fields and custom  validations  • Code defensively for all inserts / updates to    sta...
Lessons Learned• Keep the interface native  • Less jarring for users  • More seamless experience    •   Familiar navigatio...
Lessons Learned• Exception emails  • Sent anytime an exception occurs  • Very little context of problem to work with  • Se...
Questions?Thank you!James Holmesjames@codescience.com
Upcoming SlideShare
Loading in …5
×

building an app exchange app

2,612 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

building an app exchange app

  1. 1. Building An AppExchangeAppJames HolmesForce.com Architect Atlanta • San Francisco
  2. 2. Agenda• Intro• Goals• AppExchange Overview• Building An App• Packaging An App• Upgrading An App• Lessons Learned• Conclusion
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Distributing An App• AppExchange for CRM• TrialForce otherwise
  13. 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. 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. 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. 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. 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. 18. Lessons Learned• Exception emails • Sent anytime an exception occurs • Very little context of problem to work with • Setup a group email
  19. 19. Questions?Thank you!James Holmesjames@codescience.com

×