One of my clients that I’ve posted about often in the past has a portal (now a Salesforce community) for their staff to manage daily class attendance & experience, control enrollments, manage teaching details, and measure success. We would love to fully skin this experience with Skuid, so that the entire UI is consistent and more under our control. This would allow us to get away from the requiring standard Salesforce tabs to navigate around, giving us more presentation flexibility, for instance. I’ve seen this type of solution nicely done in Skuid demos, so obviously in general this looks great. However, we see significant hurdles to in this particular implementation.
Primarily, we are making use of several Salesforce features that cannot be easily re-skinned, such as reports, dashboards, and content/files. How have projects dealt with this issue? Are there examples that show how to incorporate these features into a highly customized UI that we can see and learn from?
In addition, what are the best practices around recreating the unique features housed in the standard Salesforce header? Perhaps there are components that we can plug in to replicate login/out mgmt or global search that we can easily implement?
We want a solid, supported solution that doesn’t resort to URL hacks, but don’t see a way to address these concerns with Skuid alone. We also don’t want to “re-create the wheel”, as presumably these issues have been addressed before.
Concerns with a fully-skinned experience
+9+9We have an OEM managed package with similar goals: The end user shouldn’t have to see Salesforce. We originally wanted to make it a completely whitelisted experience, however, more and more we have been accepting the fact that some things cannot be reskinned. With that being said, all of our pages are child pages with a master page that hides the SF header/sidebar, global navigation, and global search. This works very well for us, and many users do not know it is Salesforce. Have you used the Skuid header and global search? For us, this replaces the need for the standard header completely.
For reports/dashboards, we use Skuid charts/graphs. I actually prefer the look and feel of these over Salesforce’s. However, the end user doesn’t get to put together their own reports outside of allowing them to filter the source data. You could probably get very fancy with creating models in javascript based on client inputs and using that to drive the source of a chart. We have not gone down that path before.
For files, we use the Skuid files object for uploads and displaying. I have not tried to use the standard content/file functionality with Skuid.
We’re a little different when it comes to login/logout since we use TrialForce for OEMs which allows a customized login experience. For logout, you can redirect to this URL ‘/secur/logout.jsp’ to logout. For login, you can use mydomain in salesforce to customize that look and branding. Communities also has a nice interface for building a custom login screen.
Ultimately, you have to get creative to keep everything inside of Skuid. For things like automatic emails, using a hidden field updated by a row action to fire an email has worked well for us. At the end of the day, not everything can be replicated in Skuid (for now). We even created our own email template functionality using javascript in an effort to replicate Salesforce’s email templates.
I’m happy to speak to any other specific workarounds to keep everything Skuidified.
+11We are getting there as well - 100% of our user pages are Skuid (detail pages and tabs) and we have partial on Home pages. Nothing on reports or dashboards, although most skuid object tabs have an Analytics tab we created so they can dynamically create reports / charts to see what they want. We haven’t had good user adoption of Salesforce reports and dashboards anyways. There are just too many limitations, and the users get confused by seeing all the fields on the object and don’t understand which field (which price field??) is the one they want in their report. So they don’t even attempt to build their own, and they call us. And we build them a Skuid report (most of the time.)
We have not replaced the SF header / search in our org.
We do have a full SF community (customer plus and partner, custom domain - no SF or Skuid url references) completely built in Skuid. We are a manufacturer (we make fiber optic cable and components sold to customers like Electric companies, Telecom providers, guys like Amazon/google/facebook) and our customers use our community to look up their order status and shipment info, invoices (like an amazon account). We’ve just released a fully Skuidified Content area in our community which meant getting into the sausage making of the Salesforce CRM content area. It was tricky but do-able once you understand the library - version - document relationships, and we build a cool search screen to replicate the sorta-ok one that Salesforce has on their native content tab. Our internal view of Content is still native SF. It just hasn’t floated up as super important to build a Skuid version right now. Our community is fully skinned - Skuid header and search, incorporates the Logout function (just a url) and the user has no idea they are in Salesforce.
We have also replaced emailing using Skuid actions, (still using either Apex templates or standard SF templates.)
For us, we are completely bought in and won’t build a single new feature without using Skuid.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.