building an app exchange app


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

building an app exchange app

  1. 1. Building An AppExchangeAppJames 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 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