Showing posts with label workbench. Show all posts
Showing posts with label workbench. Show all posts

Sunday, April 3, 2016

Painless Removal Of Boat Anchors

I asked my Auntie Pat Tern why she has a tattoo of a boat anchor on her forearm and she said, "Boat anchors symbolize hope, but I'm considering getting this one removed." So she didn't have it to enhance her resemblance to Popeye like cousin Tim Toady always says.

It may have been hope that also inspired the boat anchor I found in the code in my org. In technical circles, some people only think of boat anchors as that outside technology they got stuck with because their boss bought it without conducting a technical review. But if you aren't constantly conducting a technical review of your own code, you can get stuck with boat anchors there as well.

In my org, I found something like the following:

All code that had once handled business logic was commented out to the point where the code literally did nothing but returned a null value. I think this boat anchor represented the developer's hope that the original code might somehow be useful later. If that's the hope, the code can be stored outside of our production org.

To remove it, we just needed to correct any references and delete the class and its related unit test. Salesforce offers multiple ways to accomplish this using the IDE, the developer Workbench or the Migration Tool, all of which are much less painful than Auntie Pat Tern's tattoo removal.

With Workbench, for example, you can simply mark a class or trigger as deleted or as inactive to remove it from production using the following steps after downloading the class or trigger files:
  1. Edit the XML meta file for the class or trigger to change its status from <status>Active</status> to <status>Deleted</status> (for classes) or <status>Inactive</status> (for triggers)
  2. Put the both the .XML file and class or trigger file into a folder named "classes".
  3. Create a package.xml file to list the class or trigger to be deleted or made inactive.
  4. Place both the package.xml file and the classes folder into another folder inside a zip file.
  5. Specify this zip file after you select Migration>Deploy in Workbench.
A great way to generate a package.xml file to get you started is to use Setup>Create>Packages in Salesforce and add the classes or triggers that need to be deactivated or deleted. This package can then be specified for download in Workbench using Migration>Retrieve. The zip file will need to be changed as described above to deploy. (For step-by-step instructions, click here.)

Like Auntie Pat Tern, be on the lookout for boat anchors and consider removing them when they pop up during your org's ongoing technical review.

Sunday, July 13, 2014

Leveraging List Views With Salesforce1

The good thing about Salesforce1 is that you have to rethink your user experience and data access for mobile.  Yes, I said good thing because rethinking data access with the mobile user in mind will result in a better user experience for someone on the road than shoehorning everything from the desktop onto a more limited device would.  With Salesforce1, you can provide mobile users with access to data specific to their needs while on the road thanks to Flexipages.

Try something different just for mobile users.
A local nonprofit where I occasionally do volunteer Salesforce development work wanted a mobile app to provide users with quick access to specific groups of records.  These users need to update about 200 or more records a day using a mobile device.  And they want some flexibility regarding the order in which these records might be accessed.

My first thought was to create Visualforce pages that would offer specific groupings of records, but the nonprofit really needed something more flexible.

So I turned to Flexipages to solve the problem.  With Flexipages, you can design a mobile-specific interface that relies on List Views to provide access to specific groups of data.

At their most basic, Flexipages simply define which List Views for a specific object should be incorporated into the mobile experience, including the Recent Items list.  If you can create a List View that prioritizes Accounts Needing Attention, for example, the mobile user can bypass the Accounts Tab and just access that list with a Flexipage.

But Flexipages don't merely offer a single List View, they can combine multiple List Views and Global Actions all in the same screen.  So a Flexipage might offer access to Accounts Needing Attention and Currently Discounted Products all with a single navigation graphic, in addition to a Global Action for creating a New Contact.

In crafting a mobile experience for your users, consider creating Flexipages and putting them at the top of the navigation menu, above the standard tab navigation options like Account and Contact Tabs.  This gives  users more immediate access to specific records of interest to users on the go.

For the nonprofit, I created several new List Views to combine different records on the same page.  I also added an image formula to signify which records had been updated on the road to help the user easily determine which records still needed attention.  You can read more about using images with Flexipages in a recent post.  I also created about 10 different Flexipages to provide the most flexible access to all the records they update via mobile.

Flexipages are easy to create as text files outside of Salesforce.  They are XML files, which are simply text files with specific textual "tags" enclosed in triangular brackets.  For example, "<description>" is a beginning tag and "</description>" as an ending tag, while the text between these two tags would be the actual description.

Once you create a Flexipage, the easy option for deploying them, currently, requires placing them in a zip file with a particular directory structure and naming convention, and including a second XML file listing which Flexipages to deploy.  The zip file can be deployed with Salesforce Workbench using Migration>Deploy.

For more information about creating Flexipages, refer to the documentation here: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_flexipage.htm

Once you consider which data is the highest priority for mobile users, simple List Views, combined with Flexipages, provide the view your mobile user needs to the data they most want.