Sonoma Partners Microsoft CRM and Salesforce Blog

5 Ways Vibe Can Make Your Business More Agile, Save Time, Boost Teamwork, and Generally Save the World

This isn't your dad's business. You have employees and partners spread all over the world and the information that makes your company successful is in their heads -- not on paper. Many of your employees work outside the traditional office and check in from home, their local Starbucks, and on-the-fly office spaces. 

A worldwide presence and a dynamic work environment are a boon for your business, but there are some drawbacks too. Since some of your employees work from home, those vital water cooler chats to catch up on company news are a thing of the past. Moving fast is hard when your project team and your sales team are in different time zones (or even just in different offices in the same building). And your project and delivery teams have no clue what's in the sales pipeline, making it difficult for them to gear up for new projects.

Here are five ways that Sonoma Partners’ Vibe Social Networking application can boost your business by getting all your employees -- no matter where they are or when they work -- on the same page.

1. Vibe is as easy -- and fun -- to use as social media (minus the annoying Farmville updates).

You might already stay in touch with your friends and family using social media like Facebook and Twitter, which you can access from anywhere, anytime. Vibe is a social CRM platform for businesses where users can post information, subscribe to feeds, and more. Vibe helps your company take advantage of your geographically diffused workforce -- and the collective brainpower of all your employees -- through a technology that your employees are already familiar with.

2. Vibe lets your employees get help with projects, proposals, and more.SocialNetwork

With Vibe, your employees can create their own feeds for each new opportunity, order, or case; post requests for help and get immediate responses from the entire organization; and deliver solutions based on other members' experience instead of starting from scratch with each new sale or proposal. Vibe also lets users search posts for information they may have missed so they don't duplicate requests, and receive daily e-mail digests so they don't miss important information.

3. Vibe lets you work like the wind.

The pace of business is getting faster by the day, so when you get a client request you need to marshal your resources and employees and get your clients what they need, stat -- which is hard when your employees (and the data in their brains) are scattered globally. With Vibe, instead of having to spend hours sleuthing out the right person or resource, employees can simply post a quick note that other subscribers to that feed can see and respond to pronto.

4. Vibe builds strong teams.

Employees work better together when they share a personal connection. Just for fun, feeds like @sports and @musicnerds foster an enjoyable work environment and help build loyal teams.

5. Vibe keeps you in the know.

Want to know what's going on in the trenches in your organization? Management can use Vibe to follow key conversations, keep abreast of new projects, and find out when someone needs help.

The result? We hate to use the cliché "well-oiled machine," but with Vibe that's what your diverse employees and partners will work like. Solutions are better, responses are faster, and key data -- from product fixes to who's following which sports team -- are where your employees need them.

Please contact us for more details on how Vibe can boost your business! If you’re already running Microsoft Dynamics CRM 2011, you can download the free community edition of Vibe from the Dynamics Marketplace.

Upgrading to CRM 2011 - Our Story

We have recently upgraded our own production Dynamics CRM system.  There are numerous sources of upgrade information, best practices, how-to's, etc floating around. The main one you should read and consider is from the Dynamics CRM 2011 implementation guide.

This post is not an in-depth exploration on how to conduct an upgrade (see the implementation guide for that), but more of the some of the decisions, issues, and thoughts we went through during our own upgrade.

First and foremost, you have to PLAN your upgrade.

You need to understand the following:

  • Updates & customizations
    • Script
    • Plug-ins
    • Custom web pages
    • Custom reporting (custom SQL)
    • Services
    • External integrations/applications
    • SharePoint
  • Hardware
    • Are you doing an in-place upgrade?
    • Is your hardware 64-bit capable?
    • Can you bring up new servers or have to use the existing ones?
  • Components installed
    • IFD
    • Email Router
    • Outlook Add-in
    • Reporting Connector
    • 3rd Party applications (such as ExactTarget, Hoovers, etc)
    • Etc
  • Logistics
    • How big is your current db?
    • How extensive is your customizations?
    • Have you done anything unsupported?
    • How much downtime can you allow for the upgrade?

 

Here is some quick stats on our system:

  • About 45 GB database (upgraded or migrated from the old v1.0 days!)
  • Customizations are fairly basic, contained around a few external web pages, a lot of script, a few plug-ins/workflow assemblies
  • External integrations (corporate web site, Quickbooks, data mart, Word Add-in, etc)
  • Client applications (such as Time Entry, Vibe social networking)
  • Custom filtered lookups and field-level security functionality
  • ExactTarget and Hoover's installed, along with a few of the Microsoft accelerators
  • We also had some simple, custom SharePoint library redirects
  • 1 web server, 1 database server (with Reporting Services), SharePoint server
  • Outlook client across 60+ users
  • Upgraded over the weekend and have everything ready for the organization that next Monday.

As we began our planning, the first thing we had to do was upgrade our web and database servers to 64-bit. As a result, we decided to purchase a new server for the web front end and choose to upgrade our SQL Server, since the db hardware was 64-bit capable already. This allowed us to configure and test the server ahead of time. Also, since we also had to upgrade our SQL Server to 64-bit, we decided to upgrade our production SQL server to 2008 R2 as well.

 

Then we did the following high level steps:

  • Backup the production db
  • Imported into development environment
  • Regression tested the functionality in CRM 2011, noting everything that didn't work
  • Updated code, customizations, etc on dev (see recommendations, but we focused on native customizations, script, and SQL changes)
  • Created solution package(s) for production deployment
  • Upgraded production db (we did this by taking a backup of the 4.0 database and importing into our new production CRM 2011 environment, since we brought in new hardware)
  • Import dev solution changes
  • Configured new teams, field-level security, enabled auditing, setup document library
  • Configured email router, report connector
  • Tested, fixed issues
  • Took another backup of the database
  • Removed extra entities, attributes, etc for clean-up
  • Deployed Outlook to a smaller pilot group
  • Rolled out Outlook to rest of the organization
  • Upgrading remaining code (see recommendation below)

Recommendations / Tips

  • Try to limit focus of the upgrade
    • You will have needs to include new functionality and approaches, but the more you can just update what you currently have, the easier it is to pinpoint issues from the upgrade, as opposed to issues from new code/functionality.
    • For instance, I would like to clean up my business unit and security role setup. I chose to wait on those updates until AFTER we upgraded, so that I could be sure things worked as they should after the upgrade, as opposed to it being to my clean up.
    • Another example is altering the schema.
      • There are couple of areas that would be prime for a custom activity or I may want to change the relationship. I believe it is far easier to upgrade everything as is, get people working and then make those changes, as there is less to test and it will take less time to get the upgraded completed.
  • Do a Test Upgrade in a development environment
    • Use the new Solution Dependency Tracking, assembly, & Web Resource lists
      • CRM will upgrade all script and images into web resources. I went through this list to understand all the code in the system
      • Similarly, all plug-ins now display in the solution. This made it really easy to see what was in the system.
    • This also allows you to test the upgrade and functionality to give you a baseline.
  • Use as much of the native functionality as you can
    • I removed all our old filtered lookup and field level security scripts and replaced it with the native tools. Same holds true for the forms with sub-grids (which we had previously done with JavaScript)
    • Further I replaced our custom audit with the native audit and our custom document library links with the native SharePoint document library functionality.
  • Take copious notes!
    • I took careful notes of the following:
      • Entities I updated, including ones I wanted to audit
      • Entities, plug-ins, etc I removed.
    • I also keep a log of all the steps I wanted to do for the upgrade.
      • This was critical that we didn't forget steps as we got going
  • Consider upgrading custom code in this order:
    • Scripts
      • Our scripts seemed to have the most trouble working after the upgrade. We had a manageable set of scripts, and many were nullified with the new functionality (inline form grids, filtered lookups, etc)
    • SQL (reporting)
      • Note that deletionstatecode and owninguser fields are deprecated. As such, any custom reporting scripts using those fields will need to be updated to work.
    • Everything else (plugins, etc)
    • Reasoning:
      • The scripts and SQL needed some TLC to work properly, but all of our plug-ins and external applications using the SDK worked like a charm against the old end points!
      • Now, I will go back and move to the new WCF end points, but I didn't need to hold up the entire upgrade for this work to be complete and it means we had less issues with regression testing.
  • Don't forget the new security privileges
    • Custom security roles aren't updated with some of the more core pieces you will need access, such as read privileges to Web Resources, Charts, Dashboards
    • Note the native security roles are updated with the base privileges.
  • Remove ALL isv.config links prior to upgrade and put them back in yourself in development
    • The ribbon XML is extremely complicated to follow and the naming convention of the upgraded nodes is systematic, but not super clear. I found myself fighting random issues more due to trying to update existing upgraded XML, instead of just adding the nodes myself.
    • Along those lines, give yourself some time to work with the ribbon. That was probably one of the areas that took us the most time to update.
  • Clean out your WorkflowLogBase and AsyncOperationBase tables (if they are large) of any processed workflow instances prior to the import.
    • CRM 2011 will attempt to upgrade every workflow process instance to WF4.0 and it takes a really long time, depending on the volume of workflow instances. If you don't need some of those old process instances, then remove them prior to import/upgrade.
  • Bring up a new environment if at all possible.
    • I know many budgets don't allow it, but it simplifies testing and allows you to work out all the connection/authentication type things that can crop up on you. Further, and most importantly, you have a very easy rollback situation in case things get dire during the actual rollout.
  • Have users help test both in dev and immediately after the rollout!
    • This goes without saying, but some of your power users will uncover functionality, issues, etc that you probably didn't know was being used

Upgrade Issues We Experienced
(Keep in mind we upgraded prior to UR1)

  • Workflow rules
    • We had (and are still having at the time I write this) some issues with some upgrade workflow rules being properly evaluated. I'll update this article once we have a solid fix.
  • Reporting connector and email authentication
    • We had some auth issues that had to be resolved after the upgrade. It wasn't difficult to resolve, but just be sure to test the reporting area and any wf emails thoroughly.
  • Outlook 4.0 client *should* work against CRM 2011, but we had some users who had trouble with tracking data from the 4.0 client. We just pushed up the rollout of the CRM 2011 Outlook client, and that rollout went pretty smooth.
  • Various product defects
    • Most are minor and some should be addressed in UR1.
    • We didn't hit any showstopping issues, which was great!

Workflow Utilities for CRM 2011 On-Premise Editions

A long, long time ago (think 2008), I wrote a blog post and provide some simple code to provide the record id and subsequent url's for workflow alert emails. As we moved into CRM 2011, I have some good news and some bad news.

Good News:

  • The upgrade of this utility worked like a charm for our production system.

Bad News:

Even though the original assembly upgraded fine, I went ahead and rewrote the assembly to leverage the new WF 4.0 and activity pattern that the CRM 2011 SDK is promoting. What is even cooler, is that now with CRM 2011 Solutions, installation (and removal) of this utility is a snap!

Download the managed solution, and import it into your Dynamics CRM 2011 On-premise edition. Once installed, you can access the utilities by clicking Add Step in the workflow editor.

image

Select Url Builder and update the input parameter with the url for your CRM system. Replace server and org with your correct values, and also replace entity with the appropriate entity (such as lead, account, sonoma_project, etc)

image

That's it! Now you can use the output values from this assembly in your workflow rules. The Url Builder returns 3 values:

  • Entity Id - The GUID of the record that instantiated the workflow process
  • Formatted Url - The url from the input property with the entity id formatted in HTML. Very useful for alert emails, as it will automatically be hyperlinked.
  • Output Url - This is the url without the HTML formatting. This can be useful if you are using it to populate a field or integrating into another application that may do it's own formatting.

I have also included a simple method (Format Line Breaks) for taking text with new lines (\n) and formatting it with HTML < br > statements which provides better readability for emails that include text area attributes in their message.