Is there a way to use custom CSS with the Customer Portal in a reliable and maintainable way?

On’s Customer Portal marketing page there is a video with an example Customer Portal from Dell. The portal in the video is obviously using a lot of custom CSS which I know can be included in the header or footer HTML of the Customer Portal.

Is there a guide, preferably published by Salesforce, for overriding the base Customer Portal CSS? Is it safe to assume that if the CSS is overridden that changes to the Customer Portal by Salesforce won’t break it?

I’m hoping that there is a reliable and maintainable way to override the CSS since the demo Customer Portal by Salesforce is doing it, but I didn’t see anything in the Customer Portal Implementation Guide.


Yes, they provide some limited advice which you’ve probably seen 🙂

No, there are no guarantees they won’t turn on a better UI.

But the portal does look like dogs’ balls, so here are some tips:

  1. utilize the JavaScript UserContext.siteUrlPrefix in the header document to resolve the correct relative path to the CSS resource like this:

    <script type="text/javascript">
        "<link " +
            "href='" + UserContext.siteUrlPrefix + "/resource/portalCss'" +
            "rel='stylesheet' " +
            "type='text/css' " +
  2. if significant changes are needed, there are a couple of ways to get a clean canvas. A very high specificity CSS reset can be used, or it is possible to dynamically remove the existing stylesheets with JavaScript.

    [I can email you a portal-specific example of a high specificity reset.]
  3. study the underlying markup to reverse engineer which structures belong to which components (you’ll be able to grok pageBlockSections, pageBlockButtons, etc)

    table#bodyTable td#sidebarCell {
        /* the left bit  */
    table#bodyTable td#bodyCell {
        /* the right bit */
    table#bodyTable td#sidebarCell div.sidebarModule {
        /* narrow home page components  */
    table#bodyTable td#bodyCell div.bPageBlock {
        /* wide home page components and page blocks */
  4. because the customization mechanism is the insertion of a Document (!) in the header, one may prefer using @import in the CSS rather than the standard <link />s in the Document; this offers future developers ‘principle of least astonishment’ so they need only modify the CSS resources, not the injected Document

  5. like any CSS files, the URLs of the javascript will also differ depending on whether the Portal is bound to a Site or not (and again if one uses [Login As Portal User] from the CRM). Using a script loader will prevent having to change the Document, and from clobbering all paths with UserContext.siteUrlPrefix. Here’s an example:

        scripts = document.getElementsByTagName('script'),
        source = scripts[scripts.length-1].src.split('?')[0],
        url = source.split('/').slice(0, -1).join('/')+'/',
        load = function(file) {document.write(
            "<script type='text/javascript' src='" + url + file + "'></script>"

LaceySnr is right about it being risky if they roll out a new theme.
One runs the same risk when styling any Visualforce. Just consider a fallback strategy in the face of changes to the underlying markup. If the new theme is an improvement, that strategy might be to simply turn off any customizations.

But there are two extremes. At one end, foist the out of the box implementation on customers at the expense of their experience. At the other, attempt to reinvent it all at the expense of not leveraging the platform offering.

It depends on the situation. “I need a visually acceptable customer portal solution in the next couple days” versus “the wireframe says it has to look exactly like this, be 100% future proof and my budget is unlimited”. There’s a Pareto principle middle ground.

Portal is pretty yukky for the guy doing the CSS, but it can be a quick win if you know the gotchas.

portal home
create case

Source : Link , Question Author : Peter Knolle , Answer Author : Matt and Neil

Leave a Comment