Salesforce continues to add to the ever expanding places in which developers can extend Lightning Experience using standard or custom Lightning Components. In a recent blog i covered Lighting Component Actions. This blog focuses on the Utility Bar. While also showcasing the Base Lightning Components also new for Winter’17.

If enabled, this displays a rectangular region shown in the footer region of Lightning Experience (it does not apply to Salesforce1 mobile currently). Regardless of where the user navigates, it remains present and its contents always visible. Its display and content is dependent on the currently selected application (just like tabs are in classic). If your from a Windows background it will likely remind you of the status bar!

Salesforce have utilised this for their new Lightning Voice functionality. Providing you have the required license for it, you can enable it under the new Application Manager. There just one hitch. For now there is no general Setup UI to configure your own utility bar or for that matter, add components to it, at least not until Spring’17 anyway.

However worry not! There is Metadata API support available now (in pre-release orgs only as i write this blog). This is all we need to unlock the power of the utility bar! Which means it can also be packaged (as part of your CustomApplication metadata) and accessed via the Migration Toolkit. Eventually also within IDE’s once they catchup with API v38. I am told however that Tooling API support is planned for Spring’17.

Sample Utility Bar Application

If you cannot wait to go try out the utility bar at this point, click the Deploy to Salesforce button below and it will deploy a sample application (make sure to use a Winter’17 org). Once deployed go to the App Manager under Setup and assign the Utility Bar Demo application to your profile.

Alternatively if you want to clone the repository and have Ant installed. You can edit the sample FlexiPage included and use the ant deploy command deploy your changes. Be sure to enter your org login details into the build.properites file. If you have managed to contain your excitement and want to know more, read on…

Updates to the FlexiPage Metadata Type

The utility bar content is driven by a Lightning Page or better known behind the scenes as a FlexiPage. FlexiPage’s have different types (see the type field in the docs). A page of type UtilityBar cannot be created with Lighting App Builder. So it must be expressed in its Metadata API form. This is what such as FlexiPage looks like…

    This page contains the Utility Bar components
    
        
            
                eager
                decorator
                true
            
            
                height
                decorator
                400
            
            
                icon
                decorator
                touch_action
            
            
                label
                decorator
                Buttons
            
            
                scrollable
                decorator
                false
            
            
                width
                decorator
                300
            
            buttons
        
        utilityItems
        Region
    
    AndyUtilBar
    one:utilityBarTemplateDesktop
    UtilityBar

This is pretty much what a standard FlexiPage looks like with a couple of differences. First the type is set to UtilityBar. Second component attribute values now support a new decorator type. This means that the attribute value is used to configure a dynamically created UI around (wrapped) your component when the user opens it from the utility bar. Rather than being passed to the component itself.

You can mix the two attribute types, those passed to your component vs those used by the wrapper. The formal list of decarotor attributes for utility bar components has not yet been documented, those above can also be seen in the Voice Utility FlexiPage. I’ll be sure to update this blog when they are. Meanwhile this is what the API docs have to say…

If this field value is decorator, then the ComponentInstanceProperty values apply to the component decorator for the Lightning component. The component decorator is a wrapper around a Lightning component. The decorator can apply additional capabilities to the component when it renders on a specific page in Lightning Experience. For example, you can configure a component decorator around a component on the Lightning Experience utility bar to set the component’s height or width when opened. The UtilityBar is the only page type that supports component decorators.

Updates to the CustomApplication Metadata Type

Once you have defined your FlexiPage you need to reference it from your CustomApplication metadata. This is as simple as specifying it via the new <utilityBar> element (see docs). There are also quite a number of new elements for branding etc.

    
        #1589EE
    
    Large
    Utility Bar Demo
    Standard
    standard-home
    Lightning
    UtilityBarDemo

Lightning Component Requirements

The above example uses some simple custom Lightning Components included in the accompanying repo for this blog. The only requirement for a component to appear on the utility bar is it has to implement the flexipage:availableForAllPageTypes interface. The follow shows the new Winter’17 lightning:tabset base component.

The components included in this demo showcase the Base Lightning Components examples from the current documentation. I have no doubt the community will be digging into these very soon. So far they look very solid and quite feature rich.

Summary

I am eager to see how this feature rolls out further, as there is so much potential for this feature in reducing navigation overheads and thus improving user productivity. I’ll certainly be exploring a bit further with this sample to see what events and interactions are possible, which i’ll surely follow up on in a future blog.

When i first heard about this feature in Winter’17 preview webinar i was very excited to try it out and not having a UI was of course not going to hold me back! Thanks to Eric Jacobson for helping with early pointers that helped me pull this together.

I think its a great move for Salesforce to deal with the juggling priorities vs development resources by deploying new features via API only if needed and as i have said before a true testament to their commitment to their API first strategy.

IMPORTANT NOTE:
As per the usual Salesforce Release Notes documentation warning. Until Winter’17 goes out to production, information in this blog and associated information should be considered subject to change. I will continue to monitor for updates in the documentation and update accordingly.