Skip to main content

ISV App Strategy

App Type

  1. ISVforce App
    • app that extend Sales or Service Cloud
    • can be sell only to existing Salesforce customer.
    • if we use some Salesforce licence dependencies feature, need to make sure the user also have licence from Salesforce.
    • our customer have to purchase the license from Salesforce
    • Licence type mostly Sales and Service cloud
  2. Force.com Embedded app (OEM Embedded app)
    • app that does not rely on Sales cloud or Service cloud functionality.
    • can be sell to existing customer or customer who does not use Salesforce at all.
    • have access to App Cloud platform.Although they have access to certain Sales and Service cloud object such Leads,Opportunities they can't surface those to customer.
    • by contract,Salesforce does not give permission to rebuild Sales or Service Cloud functionality within OEM Embedded app.
    • the licence is embedded in application for new customer and existing customer but existing customer can choose to assign their ISV app licence rather than using embedded user licence.
    • Licence type Force.com,Customer Community (optional) and Customer Community Plus(optional)
Both ISV application licences provided by partner.

Why would you want to build an ISVforce app instead of an OEM Embedded app?
The app displays data in Opportunity and Lead objects.


Why would you want to build an OEM Embedded app instead of an ISVforce app?
Your target customers may not already have Salesforce.


What kind of Salesforce licenses must be included in a OEM Embedded app?
Force.com


In your special partner DE org, you’ve created an app that you are ready to distribute. Displaying data from which object in your solution would prevent you from being able to use the OEM Embedded app type?
Case . We still can use Account and Contact in OEM Embedded app type.


Trailhead :Select an App Type

Comments

Popular posts from this blog

Search Solution Basics

When is it a good time to create a customized search solution? You're developing an external knowledge base for user support. You're in the mood for a fun Friday night. The sales reps just started using the Sales Cloud in Lightning Experience. You want to put your company branding in the search bar. What differentiates SOSL from SOQL? Syntax SOSL searches the search index instead of the org database. SOSL searches more efficiently when you don't know in which object the data resides. All of the above. SOSL works with: REST only SOAP only REST, SOAP, and Apex SOQL only What does a search for a single object look like in SOSL? FIND {cloud} RETURNING Account FIND in ACCOUNT RETURNING "cloud" FIND "cloud" in ACCOUNT FIND (cloud) RIGHT NOW! What does a search for multiple objects look like in SOSL? FIND {sneakers} RETURNING ALL ARTICLES FIND {sneakers} in ALL OBJECTS FIND {sneakers} RETURNING Product2, Content

Process Builder is not fired when field update is called from Approval Process

Scenario In Final Approvals section ; in Approval Process we have field update to update Status field. In Process Builder , we have some action that need to be done when Status field is updated in Approval Process.However this process builder is not fired. Solution To handle this, in Field Update in Approval Process , check Re-evaluated Workflow Rules after Field Change as picture below. What happen if field updated from Approval Process. Workflow - does not fires untill Re-evaluate workflow checkbox is ticked on your field update Process Builder - does not fires untill Re-evaluate workflow checkbox is ticked on your field update Trigger - will fire if conditions are matched This is explained in article here  . Field Updates That Re-evaluate Workflow Rules If  Re-evaluate Workflow Rules After Field Change  is enabled for a field update action, Salesforce  re-evaluates all workflow rules on the object if the field update results in a change to the value of the fi

Tips and Tricks : Test class for Invocable method

Issue : I got 100% coverage in my sandbox but when run validation for deployment it returns 0% coverage It turn out that in my sandbox, I am depending on Process Builder to Invocable Apex class, as long I manipulate test data that fire Process Builder it will call Invocable class. This is not useful when deploying it to Production although it gets deployed together with Process Builder. The correct way is to direct call Invocable method inside test class itself. Example of class : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 global class MyCustomObject_StatusUpdate_Util { @InvocableMethod ( label = ' Update Quote Status ' ) public static void updateQuote ( Request [] requests ) { Set < Id > setOppId = new Set < Id >(); List < SBQQ__Quote__c > listQuoteToUpdate = new List < SBQQ__Quote__c >(); for ( Request request : requests ) {