7

I have a situation where a user would like access to a managed package object without having a license for that managed package. The end goal would be to have an apex class that can spit out the contents of that object.

I've tried a couple things as the unlicensed user:

1) Simply querying the object via developer console query editor. This results an exception saying "sObject type 'MANAGED_Example__c' is not supported"

2) Creating an apex class "without sharing" to query the object. This results in no errors but an empty result set when there should be data.

3) Creating a custom object and a trigger on the managed package object to keep the two in sync. This works ok but seems less than ideal.

Does anyone have a better idea on how to do this?

4
  • 1
    You could expose the managed package object via an Apex SOAP web service or the Apex REST API. Commented Apr 9, 2013 at 21:38
  • There are numerous ways to do some form of what you want, but from a business risk / ethical perspective, you definitely want to ask yourself: would my vendor be OK with this? If so, then ask for their advice; if not, then you'll need to be careful because even if it's technically not a license violation (and it may certainly be), the vendor can choose to revoke or not renew your license if they come across this.
    – jkraybill
    Commented Apr 10, 2013 at 4:55
  • Just to clarify, I am the managed package vendor. The customer wanted users who do not have a managed package license to be able to view the data created by managed package users. The goal is not really to provide snapshots/reports/analytics on this data, but to provide full read only access to the custom object via a VF page. Commented Apr 10, 2013 at 12:57
  • Mike, do you have any updates on this? The current behavior I'm seeing is that regardless of license, users are able to access objects in the managed package via Apex. That means they have RWD, and you can, for instance, render the data in a Lightning Datatable. The user cannot access Record Lists or perform SOQL queries however. Commented May 14, 2020 at 15:14

2 Answers 2

3

Mike,

As you're the managed package author I think you're free/clear of ethical issues despite clamor here. As someone who's "known" you for awhile I find it amusing that the first response to your question was to question your ethics. lol.

Daniel, I think, hit the nail on the head. One of my favorite tricks, if you can call it that, is to utilize the built in salesforce ajax proxy to hit api endpoints via jquery. In this case, you could easily create a custom rest api in apex, then hit that via the ajax proxy.

The gist of using the ajax proxy is this:

var request = this.getXmlHttpRequestObject();
request.open("POST", '/services/proxy', false);
request.setRequestHeader("Authorization", credential);
request.setRequestHeader('SalesforceProxy-Endpoint', this.url);

This is a pure js version, but you can easily do the same via jQuery.

Essentially, the key points are found on line 2, 3 and 4.

  • Line 2, that middle parameter of '/services/proxy' is required! and is the url for using salesforces' built in ajax proxy. Using a relative url lets it work regardless of your instance. ;)
  • Line 3, sets the Authorization header that is used by the Proxy to authenticate your request. the variable 'credential' is the oAuth token from your session. I'll leave it as an exercise for the reader to aquire that session token id. Line 4 is the money!
  • Line 4's, this.url variable is the effective url for the request. In other words, the XMLHttpRequestObject's actual url is /services/proxy but the proxy is going to turn around and forward the request to whatever url is passed to the proxy via the 'SalesforceProxy-Endpoint' header, in our case the variable 'this.url'.

I took this example from some of my Evernote / Salesforce integration code, if you'd like to see a version of it with syntax highlighting etc. check out https://gist.github.com/da59b15f827a10fb627e

1
  • 1
    Thanks Kevin and Daniel! gist.github.com/mtetlow/5355219 is my final proof of concept. A custom REST endpoint does not seem to be impacted by the licensing restrictions, while a simple query of the object using a REST API helper like forcetk is impacted by the licensing restrictions. Commented Apr 10, 2013 at 14:42
3

I'm not sure it's OK to discuss this - obviously Salesforce.com and your managed package provider would love you to pay for couple more licenses ;)

Stuff like that tends to be tricky legal grey area similar to "I need to display some simple data from Account and Contacts on my PHP site. Do I have to pay for thousands of Customer Portal licenses or can I cheat by using some 'integration user' and querying for relevant data in the background"...

So safe harbor, blah blah blah, I don't encourage you to cheat...

Here are 3 more ideas:

  1. If you need a really high level overview - build a dashboard that's running as user who has a license. Schedule this dashboard to be emailed to your "unlicensed" users or use Chatter alerts to inform them when some milestones were met (works nicely with gauge components). They won't be able to drill down to the underlying reports but well, there's only so much you can do.
  2. Read about Analytic Snapshots. Long story short - you build a custom object to which you'll insert output of some report. It's still a quite flexible solution that's "clickable" (trigger or nightly sync job are more flexible but mean development effort).
  3. Provide the license to one "integration user" and either share the password (tsk tsk) or build your "reports", data views etc. somewhere else. Fairly painless if your company already has some integration solution (Informatica, Bluewolf, Relational Junction etc) and / or dedicated reporting team (like SAP BW guys).
4
  • Just my $0.02 that your "grey area" example is not grey, unless something's changed that I am not aware of. Salesforce does not restrict your usage of your own data once you extract it via API (provided you're within API limits). The OP's question is much more of a grey area, IMO, and potentially creates business risk of license cancellation/non-renewal if the vendor perceives it as a license violation (whether or not it is).
    – jkraybill
    Commented Apr 10, 2013 at 4:57
  • Ok, API might be indeed fine but I've seen some kind of "floating license" hacks where cust. portal user got activated and deactivated when he/she was using the portal (which was supposed to happen roughly once a month and the risk of running out of licenses used at same time was low) - this is probably worth checking with company lawyer. I'm just a dev ;)
    – eyescream
    Commented Apr 10, 2013 at 6:33
  • Wouldn't you just use overage licenses in that situation - these are based on logins per month rather than named users and are intended for the situation where you have a large number of portal users, but they aren't all constantly active. Commented Apr 10, 2013 at 7:31
  • @BobBuzzard It was my colleague who was exploring this option (I'm perfectly aware how shady that sounds :D) and I don't recall all details anymore. Maybe it'd indeed be a valid option. But at a quick glance eu1.salesforce.com/help/doc/en/… says it's not available for new orgs and there's only 1 login/month allowed... Anyway - it's off-topic here and it's not me who had to deliver this solution, no sleep lost over it ;)
    – eyescream
    Commented Apr 10, 2013 at 8:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .