I moved this to our Salesforce area of the Community where it's more likely to receive an answer.
No you dont require Sparkler if you are using SAML. Make tableau work with SAML, have Salesforce instance use same IDP settings and use Canvas to embed visualizations.
Is there any alternative method besides using SAML and Trusted Ticket (which requires a Sparkler)?
Can I just simply create a iframe in VisualForce and embed the URL of my Tableau dashboard accordingly? Since I am using Windows Authentication on the Tableau Server, I can just use Active Directory to authenticate my login.
Has anyone been successfully using iframe in Salesforce? How are the pros and cons doing things this way?
Thank you for your help.
You should be able to embed directly into Salesforce using web tabs or Visualforce page/tabs without using Sparkler.
Maybe someone else can shed some light, but the only scenario where I observed using Sparkler is helpful is this: Not all users who have access to Salesforce have (or should have) access to Tableau Server. Users who do not have access to SF, should not be able to view dashboards (that is the Guest user account is not used on Tableau Server). However, everyone who has access to SF should be able to view embedded dashboards. In this event, use Trusted Ticket.
Otherwise, embedding directly into SF using web tabs or visualforce pages seems much simpler, requiring the least amount of effort.
If you don't mind,can you please share your experience of embedding Tableau dashboard directly into Sales force.
What's the process of embedding tableau dashboard in SalesForce IFrame ?
Any inputs will be highly appreciated.
I'm not sure if this is what you're after, but essentially, you have a couple of ways to embed a page or resource into SFDC without using Sparkler: Web Tab or VisualForce Page. The methods below will require that the dashboards are either published to allow Guest access or require that your users log n to Tableau Server to see the dashboard.
You'll need to have the correct SF permissions/privileges to make the changes below.
To create a Web Tab:
1. Log into SFDC, click Setup in the upper right hand corner.
2. In the left panel, click "Tabs" under "Create" which is under "Build"
3. In the Web Tabs section, click on "New" and follow the prompts until you get to "Step 3..."
4. At Step 3, type in the type in the Shared link/url of the dashboard.
To create a VisualForce Page:
1. Log into SFDC, click Setup in the upper right hand corner.
2. In the left panel, click "Visualforce Pages" under "Develop" which is under "Build"
3. On the Visualforce Page, click on "New" and fill in the required fields.
Once you have either one of these items setup, you can customize your tabs to include them in the header.
Hope this helps.
Thanks Ivan. That was really helpful.
We see that Chrome and Firefox have no issues. But, IE, we are not able to embed the viz. Any idea ?
Sounds like a browser specific issue in this case. A few questions come to mind: Was there an error? If so, what was the error? Which method are you using to embed? VisualForce Page or Web Tab? Are you using Iframe? Are you embedding http content into a https page?
Following the instructions specified we were able to embed Tableau VIZ in Salesforce through VisualForce Page, however currently when I click on Tableau Tab I'm being prompted to login page after which the report loads. Salesforce is not SSO enabled and Tableau Server is set up with SAML Authentication SSO Enabled.
My understanding is that I need SSO enabled both at Salesforce end and Tableau end to get authentication page disappear. Let me know if my understanding is correct.
Also, I wanted to confirm if the Identity provider should be same at both end i.e. Salesforce or SAML, I feel like we can use any Identity provider either side.
There are multiple ways to do this so that you are not prompted to login:
1. Enable Guest User
2. Setup SFDC to use the same IdP
3. Or use trusted authentication (Tableau Sparkler).
If your data is not sensitive (or if your Tableau Server is only good from an internal network), and you have a Tableau core license, then you can enable guest account.
If your data is sensitive or you do not have a core license then you'll have to go with method 2 or 3. Hope this helps.
Thanks for your response. Currently we have cored based licensing and our data is sensitive so we cannot enable the Guest option.
We have done this set up earlier with Sparkler but that’s kind of big process to follow and wanted to get rid of it, so looks like my only option is to make same IDP used at both end i.e. salesforce and Tableau.
I was able to get tableau reports loaded in salesforce and able to access them flawlessly in browsers, however when trying to access the same through salesforce1 app observing strange behavior.
- When I select the “Test Tableau” App from the selection I do not see anything – it is blank screen with red bar on the top, nothing happens even if I do any action on the screen with my finger touch
- If I reselect the “Test Tableau” App a second time I still get blank screen but however if I try to do some action on the empty screen with my finger touch the processing icon of Tableau appears and the Tableau dashboard appears
Behavior is quiet strange and when looked into salesforce forum couldn't find much on the issue. Hoping to see some good response over community. Behavior is same in Android and IOS devices.
Thanks for your response.
One behavioral difference you will get with SAML vs. trusted ticket is that the user will be presented with an orange "Log in to Tableau Server" button instead of just seeing the dashboard/view appear. This will happen on their initial access of a tableau artifact, and not subsequent access - within a given session.
The "Log in" button triggers a popup window which redirects to your SAML IdP for authentication. This can be a bit of a sub-optimal user experience, but does indeed appear to be necessary for security reasons. Most SAML IdPs don't permitted iframed authentication for security reasons.
Trusted ticket avoids that, but at the cost of being a vendor specific cross-platform authentication mechanism - which may have a higher risk of undiscovered vulnerabilities (e.g. v1.02 addressed one such issue). SAML is a more battle-tested mechanism.