Custom buttons to the rescue!

We have a process by which large customers are vetted to make sure they’re following all of our best practices.  We use Cases for this work.  A case is created automatically and our team works through a series of questions with the customer, making sure everyone is on the same page.  Once this is done, the case is closed.  And there, my friends, is where we run into trouble.

You see, Salesforce won’t let you set the Status on the Closed Case page to “Closed” by default.  This means that even if “Closed” is the only reasonable status for a Closed case, the agent still has to choose it from a picklist of 1.

Well, that’s just dumb!  Here’s the Idea you can promote to make this standard functionality.

The work around is to create a custom button to default the status for you.  Here’s the code:

/{!Case.Id}/s?retURL=%2F{!Case.Id}&cas7=Closed

All it does is default the status of the Case to “Closed”.  That’s it!  But it saves my agents (customers!) a two clicks per case.  With over 1100 cases per day, that’s a lot of clicks!

Advertisements

And then there were three

I’m 1/3 of a three person team.  We became 3 in June and the addition of a third person caused some friction.  I suppose that was to be expected, but I don’t think any of us expected the level of friction we’ve experienced.

As such, we’ve had a series of meetings to come to an agreement on how we’re going to operate as a group.  Here are just a few of the questions we’ve had to answer in order to become a team.

  • How does work get to us?
  • What constitutes work?
  • How do we prioritize work?
  • How do we document work?
  • How do we plan?
  • How do we account for break/fix work in our planning?
  • How do we track dependencies on other departments and teams?
  • How do we remain transparent to the rest of the company without double entry of tasks?
  • When is a unit of work ready to be worked?
  • When is a unit of work done?
  • Who’s responsible for collecting requirements?
  • What form do those requirements take?
  • How do we track work?
  • How do we keep each other accountable without hurt feelings?
  • What role does management play?
  • How do we celebrate our successes and learn from our failures?
  • What is the definition of an “all hands” scenario?

I’m sure there will be many more meetings and we’ll end up iterating.  The whole point is to begin to come to consensus on these issues.  Wish us luck!  🙂

Documenting Custom Apps with ScreenSteps

As an administrator I spend a lot of time teaching. Teaching users how to retrieve a lost password. Teaching managers how to build custom views. Teaching the CEO that not all reports need to be on a dashboard.

While I love teaching my users one-on-one, this often isn’t practical. For example, when I roll out a new app, I can’t be in everyone’s cube walking them through it.

As I’ve mentioned before, we recently rolled out several apps. I was NOT looking forward to creating the training materials. Frankly I was dreading it. I envisioned struggles with versioning the docs, making sure my screen-shots were readable (but not too big) and general fear over the sheer volume of stuff I needed to convey!

Upon the recommendation of one of my Twitter friends (sorry folks, I can’t remember which!), I spent some time investigating ScreenSteps. Well, I’m in love!

ScreenSteps is an amazing documentation creation tool. Aside from the super intuitive UI, you can logically group your lessons into manuals and, depending on your version, put those lessons on their servers. Now, here’s the best part. Once your lessons in the cloud, you can make them available in a web tab in Salesforce!  Swoon!

It took me much less time than I was expecting to create the documentation for my app.  Once it was done, I ran it by my colleagues who (of course) had edits.  Making changes to the documentation proved to be equally easy!  All I had to do was edit the local version and push it to the cloud.  Instant updates!  I am one happy Admin!

Thanks ScreenSteps for making this Administrator’s life MUCH easier!

Entering Old Data Into A Deployed Object

When we rolled out the employee awards program I mentioned in my previous post, we weren’t sure the business would want the old data (400 awards worth) captured in Salesforce.  After the app had been live for a few weeks, it became clear that back data would need to be in Salesforce for reporting purposes.  Great!

PROBLEM: How do I give access to the data entry folks without compromising the automation that’s happening in the background of the app?  For example, when you create a nomination there is logic in the background that determines the approver and starts the process along its merry way.  This is great in production because it keeps the user from having to determine who gets the approval next.  Trouble is, these paper awards have already been approved!

SOLUTION: Why not use a sandbox?  Once the data is all entered I’ll, run a report, export the report and, using the DataLoader, put that data in production. So, I created a sandbox, disabled all the logic and streamlined the page layout for easier data entry (including removing all related lists.)

The data is about 10% entered at this point, with completion slated for sometime next week.

IsCurrentUser

We needed a custom app to track an employee awards program.  All employees are encouraged to nominate co-workers who have wow’d them.  The nomination process had involved pieces of paper floating around the office waiting on approvals in special colored inboxes.  It should come as no surprise that forms got misplaced or delayed.

With the help of my colleagues, we created a custom app in Salesforce.  The app is one object, the nomination, with approval processes and validation rules.  The nomination object has two user lookup fields: one for the nominee and one for the nominator.  These fields are necessarily independent of the record creator and the record owner for a myriad of convoluted reasons.

PROBLEM:  I can’t create a Custom View to show a user only their nominations (meaning the nominations they’ve written up to award co-workers).  The “My Record” functionality is based solely on ownership of the record.  There had to be a way to make this thing work without giving everyone access to the “All Nominations” view.

SOLUTION: I created a formula field that evaluated to “1” if the nominator was the same as the current user.  I cleverly called the field “IsCurrentUser”.  Here’s my formula:  IF(Nominator__r.Username = $User.Username, 1, 0)

When a user logs in and goes to the “My Nominations” view they see only records for which they are the nominator because the view filter criteria look like this: “IsCurrentUser equals 1”.  There will only be a total of 1200 records per year for this object, so the evaluation time isn’t onerous.

I have to say, I was pretty proud of myself for this one. Now I can better leverage the lookup relationship to the User object in all my custom apps.

Enabling Chatter

We’re a pretty young company.  Not only were we founded in 2005, but the average age of the employees hovers around 32.  Most of my co-workers are on Facebook. Some are more active than others, but pretty much everyone gets the theory.

We asked to be a part of the Chatter beta release and were granted the opportunity.  I had a lot on my plate at the time and didn’t immediately enable it.

One regular Tuesday afternoon, our CEO was two desks over asking a colleague for assistance.  There was a pause in the conversation while my co-worker did his SQL ninja-ness and the CEO flips his chair around and says “Amber! How soon can I have Chatter?”

Frankly, I wasn’t expecting him to be so enthusiastic!  I told him I would need a few weeks to get some internal buzz going, then I’d turn it on one weekend and we’d see what happened.

I met with the various departments about which fields they wanted to trigger a Chatter update.  I met with our marketing team and we made colorful teaser flyers to hang up all over the office (“Coming Soon to a browser new you…”).  I dug through my luggage to find my teeth from Dreamforce so I could bring them, conspicuously, to meetings.

When the go-live date came, I spent about 20 minutes on a Saturday afternoon enabling and playing with Chatter.

Come Monday morning, I was a bit nervous!  Would I get a thousand questions about minutiae that I couldn’t answer?  Would folks post inappropriate stuff?  Would anybody even notice!?!

They noticed!  Boy, oh boy, did they notice!  I was getting high fives in the hallway, thoughtful questions at the water cooler about possible uses, and praise for “working so hard to foster collaboration”.  It was all pretty exciting!

It has been about 3 months now and Chatter is still going strong.  Folks are sharing whitepapers, departments are collaborating on things they might not have before, and sales deals are celebrated across the organization.

Going forward, we’re likely to enhance Chatter with some of the cool AppExchange apps.  For now, I’m just enjoying the glow of being able to leverage this amazing new toolset for my users.

%d bloggers like this: