Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
By Sandor Schellenberg, Owner and Founder, friendlyITsolutions
I have worked on many Microsoft Dynamics CRM implementations
and over time I have served in a versatile set of roles. I have been part of
the team responsible for designing, building and testing a CRM application,
i.e., the implementing party side. I have reviewed implementations for
customers that needed a fresh view on their new CRM application. I have also been involved in taking the CRM
application into support as member of the IT department.
The road to your CRM application's go-live is not always smooth,
and all parties involved face different challenges. In my experience there are
usually two topics related to support that are easily overlooked or neglected.
In my earlier ‘musings' I addressed the first topic - data
migration. The second, which I know from my own experience, is preparing
for and managing post-go-live support. In most project management
methodologies, the phase after go-live is typically planned for a week or, if
you are lucky, even two. After this period the project team is dismantled and
CRM is officially in support mode.
Who writes it down?
Why? And for whom?
The first question that comes to mind when talking about
support is the infamous "D" word. I know from my own experience that this is
the least favorite task of every consultant, and yes, it is documentation. Of
course, we all know that documentation is important to an enterprise software
project because it can be used to instruct new colleagues, to guide new
development, to give insight into a solution's architecture, testing, and so
Most CRM documentation has one thing in common - it is written
from inside the project where the authors have good insight into the in's and
out's of project like important decisions, design choices, and requirements. Documentation
written from this perspective often causes issues for those who receive it from
the project team as part of the process of taking responsibility for the
application in support. The support team usually does not have the insight into
the project that adds context to this type of documentation - things like knowledge
about choices, functionality details, dependencies of code, integrations, etc.
The requirements of documentation also depend on the role of
the support team. For supporting your CRM application you will typically have two
roles: functional and the technical support.
To support your CRM application from a functional point of
view, you would need to know what kind of functionality was required by the
business. The functional support
engineer needs insight in the CRM project team's functional design, workflows
and a basic understanding of integrations. For example the engineer would need
to know the process for setting or maintaining a customer address that is
The technical support engineer needs to have insight into
general functionality of your CRM application as well as detailed information
about areas including workflows, data integrations techniques used, location of
log files, and other customizations and configurations. In general, if
something is not functioning well, then the engineer needs to know where to
gather the information to start debugging.
Beyond the specific functional and technical roles, there is
the question of how support fits into an organization. In small organizations
it could be a combination of power users from the business and your system
administrator. In larger organizations the support team's structure is often
more sophisticated, organized into knowledge areas for systems like Active
Directory, Exchange, Firewalls, Desktops, and other legacy software. Your CRM
application requires expertise from various knowledge areas, and you will face
the challenge of setting up a support structure that works closely with other
internal departments or third parties. In daily life, CRM support is like the
spider in the web, working and coordinating with several other teams.
course in a small organization the red tape for such a team is not too bad. But
in midsize to large companies it is not unusual to see several departments or
even external parties involved in providing and receiving support. It
can get even more challenging if every department uses its own standards and service
The support process
When an incident is reported, the engineer for the CRM solution
needs to rely on documentation, as well as functional and technical
understanding of the system, to determine whether the issue originates with CRM
or one of the related systems. The
bottom line for supporting your CRM application is that it requires both the
focus on the application itself and the ability to take advantage of the
expertise of the larger support organization. This sounds like a major
challenge, and it is. But setting up optimal CRM support requires the cooperation
of people with different knowledge areas and expertise.
Business Applications communities