Guest Post By Stephanie Poorman
Who am I?
My name is Stephanie Poorman, and I am the Senior Salesforce Admin/BA at Parata Systems in Durham, NC. We rolled out TaskRay almost a year ago for our Marketing team to manage their many projects, and they loved it. Recently, with the advent of a new manager and the expiration of our AtTask licenses, I convinced my own Applications Development team to adopt TaskRay as well, and they’ve even shown some actual excitement during the rollout. (It’s not just women or non-technical users who appreciate sleek aesthetics and user-friendly interfaces.)
Why use TaskRay for IT?
To be fair, TaskRay has been gaining popularity across the company. Our next rollout is for our Engineering team and will include adding some custom time-tracking functionality. The reason the AppDev team has adopted it, though, is fairly straightforward: We wanted a tool that could work within an existing system, was easy to use and customize, provided a specialized interface for project management, and didn’t focus too heavily on the nitty gritty. TaskRay is native to Salesforce, is extremely flexible, and allows us to view our projects from all sorts of perspectives (mine, yours, ours, past, future, and present). It even supports queues and has a beautiful, intuitive UI that easily switches between a Kanban board, a Gantt chart, and a task timeline. For the nerdiest among us, there are iPhone and iWatch apps.
Any cool features?
Okay, I have to admit that I’m very excited about one feature we’re getting ready to set-up: Email-to-Tasks. I still receive all my ticket requests from an external system, but some of them need more detailed planning and tracking. At first I was concerned; I didn’t want to add a lot of extra work by receiving tickets in one system and managing them in another. But then I realized - Ah ha! - I get email notifications from the current ticketing system. I can just forward the larger ones to a special email address, and - poof! - they can be magically (read: automatically and easily) assigned to my very own Change Management Project.
In addition to adding time-tracking, my manager and the Engineering team’s project manager are interested in adding dependencies between tasks (a lookup field and a validation rule) and building an approval process that will prevent users from pushing out task deadlines without approval from the project owner.
Okay, so how did the rollout go?
It was amazingly easy. I say that as the only person doing the rollout. Cross my heart, it only took two hours to add and set-up records types based on Department and convert our sharing from Public Read/Write to Private. (We opted for a Private model simply to keep the UI cleaner: we all have a lot of projects and just don’t want everyone else’s to muck up our view.)
Bracket Labs has very clear documentation on how to set-up record types here. The one thing that it doesn’t mention is that the profile of the admin setting everything up needs to be assigned all the record types, permanently, or they won’t be available in the Record Type Mapping tab. Additionally, individual users only see the “Board” filter if they are specifically assigned more than one record type, even once record types are enabled. The data migration to update existing projects and tasks was extremely easy. Since only one department was already using TaskRay, I just exported all of the existing records, added the new record type IDs, and pushed the updates back into Salesforce via the Dataloader.
Next I converted our sharing model for projects and tasks, guided by (once again) some very detailed documentation available here. I opted to create my sharing rules on Projects and Tasks first to cause as little disruption as possible to my users. The rules are simple and criteria-based: if the record type is [Department Name], then Public Group [Department Name] gets Read Access. I then updated the org-wide defaults on Projects and Tasks to Private (the background objects are not changed). The sharing recalculations, including one run automatically by TaskRay, completed quickly.
There was one almost-tricky part. At the bottom of the Project Security documentation is a little note that explains that projects automatically default to Public upon creation, no matter how your org-wide defaults are set-up. But that too is customizable - an easy five steps that takes about three minutes (seriously). After I set the default to Private, I realized that I still needed to find a way to update all the existing projects and tasks that were already set to Public. This is controlled not by a field that can be mass-updated in a list view, however, but with a manual sharing rule created by TaskRay. Turns out, you can export, insert or delete sharing rules using the Dataloader (for any object set to Private):