Wednesday, December 31, 2008

Success with Microsoft Dynamics CRM 4.0

Altriva has kept me very busy since joining them in October '08. My first project for them was a CRM 4.0 new deployment for a large manufacturer in the Seattle area. There are 12 users up and running on the system now and they're enjoying the increased information and productivity the application provides.

The group that I worked with are responsible for providing support to their worldwide dealer network. They can now access information that was previously difficult to come by such as each dealer's employee hierarchy, current and past service cases, a record of all correspondence, inventory information, and a knowledge base.

Besides helping to build requirements, installing and configuring CRM, and working with IT on architecture decisions, I also had fun (really!) working with SQL Server Integration Services (SSIS) to feed the company's master dealer information into CRM. This integration (well, ETL process actually) is scheduled to run each night using SQL Agent. The SSIS package queries from a SQL 2000 database and calls the CRM 4.0 Web Service to insert or update dealer information in CRM. The article written by CRM MVP Darren Liu helped a lot to put this integration together.

While I was working on that project, there were three people around the office that were diligently working to finish the book Success with Microsoft Dynamics CRM 4.0.

After working with several others in the past who have written a technical book (or started one) I've come to recognize that it takes an enormous amount of discipline, depth of knowledge, caffeine, understanding family members, and ability to get by with little sleep to plan, write, and finalize the content for a book like this. Watching these otherwise friendly clean-cut guys turn into disheveled and mumbling animals was not pretty to see, but they're back to normal again and we'll all be more successful with our CRM deployments because of their insanity.

Wednesday, October 1, 2008

Dynamics CRM 4.0 Quick Reference

When I've been in CRM design meetings, writing code, working with a new client, or helping someone ramp-up on CRM 4.0, I always thought it would be helpful to have a "CRM 4.0 Quick Reference" handy. I've had to rely on the reference between my ears, which isn't always reliable.

So I got up early a few days last week and put one together.

Now, I realize the content I find most valuable in a Dynamics CRM 4.0 Quick Reference is not necessarily the content you would've chosen. So, if you send an e-mail to me at I'll send the Word version of the document to you. You can then start with what I've done and tailor it to meet your needs. Of course, it would be great if you share your version with the CRM community as well!

Here's a list of the major sections I've chosen for version 1.0 of the quick reference:

Page 1

  • What's New in 4.0 ("Titan")

  • Selling Points

  • Major Product Components

  • CRM 4.0 Server Editions

  • Deployment Scenarios

  • On-Premise Requirements

  • Importing Data

  • Unsupported Customizations

  • Integration

  • Performance and Scalability

  • UI Customization (ISV.Config and SiteMap)

  • Miscellaneous

  • Reporting Options

  • Workflow

  • Outlook Client

  • E-mail Functionality

  • Core System Entities

  • Asynchronous Service

Page 2

  • Forms and Controls

  • SDK

  • Accessing CrmService (Sample Code)

  • IPluginExecutionContext Interface

  • Technologies

  • Plug-Ins (Plugins)

  • Workflow Assemblies

  • Entity Relationships


Monday, September 1, 2008

High-level tasks for a Dynamics CRM 4.0 project

In a previous post, I listed many of the technical skills that a Dynamics CRM 4.0 implementation team likely needs to possess in order to design, code, deploy, and support a truly useful and rock solid system. In this post, I'm going to share some thoughts on the roles and tasks that go into successfully launching a Dynamics CRM system.

On my CRM projects over the years, I've worn the hat of most of the project role members you'll see below - sometimes many of them at the same time. On a CRM deployment with only 10 users, I was the sole contributor - from business analyst to C# developer and everything in between. But most often I've worked on a 2-5 member team, with the largest deployment coming in at 500+ users.

Let's take a look at the hats that you might have to wear on your next project by stepping through the high-level tasks of a Dynamics CRM 4.0 project.

Needs Assessment

Goals and Tasks:

  • Gain a thorough understanding of the needs of the stakeholders and their business and end-users.
  • Identify and meet with key business stakeholders and domain experts. Ask lots of questions and write down every answer.
  • Create and distribute documentation listing the project vision, scope, risks, and assumptions.
  • Understand and communicate the project scope. What's in and what's out?
Team Members:

  • Business Analyst
  • Project Manager
  • Senior Developer

Just a thought... Isn't it awesome at this stage of the project to know that, with Dynamics CRM 4.0, you can deliver an extremely robust CRM or line-of-business application for dozens or hundreds of users in less time than it takes an average IT shop to decide between .NET vs. Java or thick-client vs. browser-based? Think about it... you're out of the gate with a solid and proven enterprise software architectural design including role-based security, web services API, metadata-driven UI and business object engine, customization tools and much more without writing a single line of code. Now, designing business objects, writing plugins, creating SRS reports, and integrating the system with other systems takes time and skill, but the point is that you can focus much more on the needs of the business and less on how you're going to provide e-mail templates, workflow, or hundreds of other features -- because many of them are already ready to go! Anyway, just a thought...

Project Plans

Goals and Tasks:

  • Define the work that will be done on the project and who will do it. This typically involves creating a statement of work (SOW), requirements specification, use cases, test and defect tracking plans, a list of resources and their availability, a work breakdown structure (tasks and time estimates), and a project schedule.
  • Requirements Elicitation: Gather, understand, review, and articulate the needs of the system's stakeholders and users. Observe current business processes, interview users and stakeholders, and distribute summaries for verification.

Team Members:

  • Project Manager
  • Test Lead

Dynamics CRM 4.0 Implementation Plan

At this point, you should carefully read the Dynamics CRM 4.0 Implementation Guide to gain an understanding of Microsoft's recommended approach to planning, designing, configuring, customizing, and deploying a CRM 4.0 system. However, as lengthy and detailed as the Planning and Installation Guides are, they don't cover many of the real-world project topics such as setting up and using a defect tracking system, utilizing a source code repository, or conducting system testing. I'll cover these topics below.

Team Members:

  • Project Manager
  • Development Lead
  • Test Lead

Project and File Management Tools

Below are some of the tools I put in place before starting in on a Dynamics CRM 4.0 deployment.

  • Requirements Management: Ideally, system requirements should be maintained in a system that's accessible to all project team members and stakeholders. In the past, I've used the customer's Dynamics CRM system (in a stable environment) for this purpose. I created a custom "System Requirements" entity and added attributes such as requirement name, id, description, priority, time estimate, key stakeholder(s), questions/answers, requirement elicitation status, implementation status, etc. If it's not possible for you to utilize the CRM system for this purpose then Excel (maintained in SharePoint, of course) works well, too.
  • Version Control: It's essential to set up a version control system (such as Microsoft Visual SourceSafe) to safely store and track documentation, source code, exported CRM XML-based customization files, and other system artifacts. Also, assign someone the task of making backups of the file repository and keeping a copy off-site (if allowed by the company).
  • Defect Tracking: Given the ease of customization in Dynamics CRM 4.0, you could utilize the "test" system for tracking defects. However, if this is not practical or possible then you'll find several excellent choices for logging and tracking the status of system defects. Systems that I've used in the past (that I've liked) include FogBugz and Jira.
  • Automated Builds: If your CRM 4.0 deployment includes plugins, custom ASP.NET applications, Windows services, or other compiled code, consider taking the extra time to automate the compilation and deployment of all software components. Tools such as MSBuild and NAnt help make full automation of builds and deployment a reality. The benefits of this type of automation are that you don't have to build and deploy manually hundreds of times (thus saving you lots of time in the long run) and you'll end-up with fast and consistent deployments.
  • SQL Server Backups, scheduled at least daily. Backing up the CRM databases will not only preserve your hard work designing entities and attributes but will also store the hundreds of lines of JScript you've no doubt written for your project. Needless to say, this is a critical task that should be scheduled and verified at least once per day.

Team Members:

  • Project Manager
  • All Developers
  • All Testers
  • System Stakeholders

System Configuration and Customization

Note: This section is incomplete. I'll fill-in the details here soon.

  • Entities and attributes
  • Forms: layout, data validation, JScript code, dynamic picklists, tabs, views
  • Navigation: SiteMap, isv.config
  • Security Roles
  • E-mail: inbound, outbound, tracking, templates
  • Reports
  • Workflow
  • Plugins and workflow assemblies
  • Custom applications: ASP.NET, IFRAME, ISV folder
  • Systems Integration
  • Outlook considerations: customizations, offline/online


Goals and Tasks:

  • Make sure that the system does what the users and stakeholders want it to do and as agreed upon in the SOW and requirements documentation.
  • Execute the test plan. Log all defects.

Many more project details coming soon... please check back for an update to this posting.

Wednesday, July 30, 2008

I just want to copy all entity notes to the Windows Clipboard!

A client called me up today and asked how she can copy all of the notes written for an entity to the Windows Clipboard. (Her company is still on version 3.0.) I told her "All you have to do is click the Notes tab on the entity record, click inside the Notes area, press Ctrl+A to copy all of the text, and then press Ctrl+C to copy the text." Her response: "Um, that doesn't work."

What!? Come on, that has to work. But then it hit me... that doesn't work... I tried that in 4.0 recently and it didn't work there either.

She needed all of the notes copied out of the entity ASAP so here's the "work around" (because isn't this really a feature flaw?!) I gave her:

1) Open the entity record.
2) Click the Print button.
3) Set the printer to Microsoft XPS Document Writer.
4) Click Print and provide a file name.
5) Open that file... it loads in IE. You can then highlight the text and copy it to the clipboard.

She said, hesitantly... "Okay, um, thanks."

The next time I'm in working on her company's system I'll create a solution (likely a report) that makes copying notes to the clipboard much easier, but if you're reading this and realize that I completely missed a built-in way of copying all entity notes please let me know!

Saturday, July 19, 2008

Getting Fiddler to work on the CRM 4.0 VPC

After loading Fiddler for the first time on the CRM 4.0 VPC, you'll likely see an error on startup. Fiddler indicates that it cannot listen on port 8888.

Here's how to get Fiddler working on the VPC:

1) Configure Fiddler to listen on port 8889. Then restart the app.

2) Rather than browsing localhost:5555 to load CRM, use this URL instead: Fiddler cannot capture requests on localhost but can when the machine name is used instead.

After making those two adjustments you should be all set!

Thursday, July 17, 2008

Build a combined activity view in Dynamics CRM 4.0

I'm often asked whether it's possible in 4.0 to view all activity related to an entity, regardless of whether the activity item has been sent, completed, or closed? Another common question is whether it's possible to view the sender and recipient(s) of an e-mail in a CRM grid view.

Perhaps those capabilities will appear in 5.0 but in 4.0 you'll have to build or buy a solution for this. One of my clients decided to have my team build this functionality and the screen below gives you a glimpse of what it turned-out like. Note that I had to gray-out some of the entries to protect private information.

Besides listing open and closed (History) activities in a single grid, we also built a preview pane to allow users to quickly view e-mail content and other activity details.

I'm not authorized to provide the source code for this solution but I can provide an overview of the solution in case you want to build something like this.

Application development: Visual Studio 2008 targeting .NET 3.0

ASPX overview: The ASPX page uses the standard ASP.NET GridView control. The middle section of the page includes a vertical resizing "control" (a table with a background image and linked JScript to provide sizing functionality). The preview pane consists of a textarea and iframe. The textarea is used to show non-HTML activity details (i.e., Tasks) and e-mail content is shown in the IFRAME.

Query: We debated whether to call the CRM Web Service to query for activities or whether it was better to use SQL (ADO.NET) via classes in System.Data.SqlClient. For performance reasons we decided to use SQL. The query consists of one query for each activity type combined with the SQL SELECT UNION clause. In the screenshot, you'll see a combobox that allows activity type filtering. We pass that selection into a parameter into the SQL query.

Grid View Columns: The activity grid view contains the following columns: Activity Type, Created On, Subject, Description (e.g., a substring of the body of an e-mail), Source (e-mail sender), To (recipient(s)), Status, Owner, Created By, Modified By, Last Updated, Priority, and Resolution. Users can sort on any of those columns.

Other Features: We also provided the ability to export the grid to Excel and the ability to delete activities that are open/pending. That last feature was requested because the client turned off the ability to delete activities for all user roles but they wanted users to be able to delete open or pending activity, such as an e-mail that was drafted but not sent.

Lastly, we deployed the solution as a virtual directory under the Microsoft Dynamics CRM 4.0 Web application. I know this is "unsupported" by Microsoft but the client had already built custom pages and placed them in a virtual under the CRM root so we went with their approach.

Let's just hope that 5.0 includes lots of new UI capabilities to make this type of view possible. And drag-and-drop column reordering, colorized rows (based on business logic), and inline editing would also be great to have!

Determine attribute utilization for CRM entities

Upgrading Dynamics CRM 3.0 systems to 4.0 has kept me very busy lately. I've been involved with four upgrades in the past few months and have more on the horizon I'm sure.

On one of the upgrade projects, the client's previous IT staff built-up the Account entity to include about 300 attributes. Now, I'm not one to quickly judge this as a bad idea without getting the facts and rationale for having so many custom attributes. Although I wouldn't have designed the entity the same way (I would've used a few picklists to replace the 100+ bit fields) the current design was built, was working, and it wasn't in the budget to change that part of the system.

But the question I had was this, "What percentage of each Account attribute has a value (is not null)?". Knowing the answer to this, and knowing what types of clients, partners, suppliers, etc. were stored in the Account entity, might lead to some decisions on whether all of the attributes are really necessary or whether a particular company type might be best spun-off to a new entity.

At the bottom of this posting I provide the T-SQL script I put together to answer the "percentage of attribute utilization" question.

After running the script, I found one classification of companies that accounted for 80% of the 150,000 Account records. But that company type only stored data in 10% of the 300 attributes! In other words, there were approximately 35,000,000 fields in SQL Server with NULL values for those Account records!

Conversely, the other types of companies stored in the Account entity utilized 90% of all account attributes. So, most account attributes were being populated, but not for a very large percentage of account records.

The problem with having unpopulated attributes is not so much the unnecessary database overhead but the complexity of the Account form when users only need to fill-in 25 or so fields for one of the records types but need to populate up to 300 fields for other account types. That leads to a lot of confusion about what data is required in the UI. Building reports, too, becomes much more difficult with so many attributes.

Here's the T-SQL script I created for this attribute utilization analysis. Again, this will help you determine what percentage of each attribute in the Account entity has a non-null value. Of course, you can tweak this code to analyze any other entity or even all entities and attributes!

set nocount on
declare @table varchar(255)
declare @col varchar(255)
declare @datatype varchar(255)
declare @sql varchar(1000)
declare @total_recs int
declare @total_non_null_recs int

declare cur cursor for
select table_name, column_name, data_type
from information_schema.columns
where table_name = 'FilteredAccount' -- tweak this
order by [table_name], [ordinal_position]

open cur
fetch next from cur into @table, @col, @datatype
while (@@fetch_status > -1)
set @sql = 'declare @total_recs float; select @total_recs = count(*) from ' + @table + ';'
set @sql = @sql + 'declare @total_non_null_recs float;'
set @sql = @sql + 'select @total_non_null_recs = count(*) from ' + @table + ' where [' + @col + '] is not null;'
set @sql = @sql + 'declare @percent_data_availability int;if @total_recs > 0 begin select @percent_data_availability = round((@total_non_null_recs / @total_recs) * 100, 0) end else begin select @percent_data_availability = 0 end;'
set @sql = @sql + 'print ' + '''' + @table + ',' + @col + ',' + '''' + ' + convert(varchar(10),@percent_data_availability)'
execute (@sql)
fetch next from cur into @table, @col, @datatype
close cur
deallocate cur

The output of this script appears, in SQL Server Management Studio, on the Messages tab in the query results area of the query window.

The ouput includes the table name, attribute name, and an integer representing the percentage of records where the attribute has a non-null value. For example, the output below means that 78% of the address1_city attributes in all records in the FilteredAccount view has a value:


In conclusion, you can use this script or something like it to quickly determine which entities and attributes in your CRM system has a value. If you see a low percentage for an attribute that you think should be much higher then that will likely lead you to take action, such as requiring values in the UI or perhaps removing the attribute altogether.

Tuesday, July 8, 2008

When a system problem occurs, start here...

Since I mostly deal with the technical side of Microsoft Dynamics CRM 4.0 implementations, including planning, deployment, development (JScript, plug-ins, workflow .NET assemblies, systems integration, etc.), I am often the person to whom system problems get escalated. One of the practices that I've found beneficial is to save all MSCRM information I can get my hands on including product documentation, KB articles, blogs, code samples, newsgroups, etc. and
index all of it with dtSearch. With a product as widely sold and used as CRM 4.0, there's likely a solution (or a solid clue) out there in the cloud and having that information indexed into a single source makes for rapid problem resolution.

Another practice I've followed is being consistent with how I record and track system problems. By recording the precise problem and/or error message(s), the status of the issue, the fixes attempted, screenshots, etc. the result is typically an organized and thoughtful approach to system diagnosis and resolution. The side benefit is that I then have documentation that may help me or others in the future. Of course, if the client I'm working with has a defect tracking system then that's where this information will go, but it's good to have a separate copy, too, so that the information is easier to locate in the future.

Below is the basic template I use when faced with a system issue. After resolving the issue, I update my personal kb in dtSearch and if I ever face the same problem in the future the solution will be easy to find.

[Client] - [Project] - Issue - [Brief Problem Description]

Date Reported: [Date]
Reported By: [Person who identified the problem]
Owner: [Tim Dutcher]
Priority: [One of the following: Urgent, High, Medium, Low]
Status: [One of the following: Open, In Progress, Resolved, Reopened, Closed]
Environment: [One of the following: Dev, UAT, Production]
Keywords: [Enter keywords that will help find this document via full-text search.]

Other details to record at the top might include: Requirement # or name, total time invested, and due date.

Table of Contents

Insert TOC here.

Issue Description

Enter full description of the issue here.

Error messages

Includes errors logged to Windows Event Log, CRM log files, IIS log, Custom log


How to Reproduce



Resolution Actions and Results

Note: Before taking any actions to resolve the issue, make backups of the CRM customizations and system files (server\bin, ISV, and wwwroot), config files, databases, and other files/settings as necessary.

[Date/Time] - [Person's initials] - Action taken and results. Also list open questions (highlight in red).

Check the following resources for information. If helpful information is found then record the URL and copy the key points from the content.

Resolution Options

List the pros and cons of each resolution option.

Final Resolution

Provide thorough, step-by-step details to resolve the problem. List the name of all files changed in source control.

Other Details

  • If debugging code, capture details of classes visited, variables, location of exception(s), commentary about code (possible areas of fault). Also record areas where additional logging would be beneficial.

Friday, June 27, 2008

Are you sure you want to navigate away from this page?

Within a form's onload script, it's sometimes necessary to override the default value of a field. On a recent project, I ran into a scenario where this became necessary for the previous development team. They implemented a custom encryption solution where client-side code called a web service to decrypt CRM data. The script then set the DataValue (field text value) of various fields to the decrypted value.

The side-effect of that code was that every time a user opened a record and then closed it (not making any changes), they were prompted with an alert box with the question "Are you sure you want to navigate away from this page? Your changes have not been saved.". Needing to click OK after viewing records became very annoying for users so they asked me whether there was anything that could be done to avoid this unnecessary message.

In looking at the SDK and the built-in code that determines whether a form is "dirty", I discovered that it's possible to set the defaultValue of a control to the current DataValue of the control. In other words, after making changes to the properties of a control (those that use the defaultValue and DataValue properties), you can reset the default value for the control to the data value that was set by other code.

My first attempt at this was to place the following at the bottom of the form's onload script:

crmForm.all.new_regionid.defaultValue = crmForm.all.new_regionid.DataValue;

I thought for sure that would solve the problem, but it didn't. Due to the placement of the onload code in the rendered page, this code ran too early and thus did not have the desired effect.

The use of the JScript function "setTimeout" did the trick, as in this example:

window.setTimeout("crmForm.all.new_attorney.defaultValue = crmForm.all.new_attorney.DataValue", 2000)

I placed that line at the bottom of the form's onload script and the unwanted "are you sure" prompt stopped appearing.

The use of setTimeout means that the user must keep the form open for at least the number of seconds you specify for the code to work. Unless someone opened a form accidentally, two seconds should allow the code to work a vast majority of the time.

Monday, June 16, 2008

What you need to know

A coworker and I were discussing over lunch last week all of the skills that a person needs to possess to properly plan for a Dynamics CRM 4.0 installation, to configure and customize the application, and to keep the application up and running 24x7. This topic came up as we talked about different professions and the level of ongoing learning that's required. For example, his fiancee is studying for the Bar Exam so we talked about the need in that profession to stay on top of the ever-changing legal landscape and courtroom rules to perform that job effectively.

Those responsible for implementing Dynamics CRM, too, need to keep on top of an ever-changing technology landscape while remaining skilled with dozens of existing technologies. When we started naming the skills needed to deploy, customize, and maintain a Dynamics CRM deployment we were surprised at how long the list became. But it explained the late nights and weekends that are sometimes necessary to do our job effectively.

Here's the list of Dynamics CRM implementation skills we came up with, in no particular order:

Dynamics CRM planning, installation, configuration
All Dynamics CRM features and functions (UI, SDK, Filtered views, etc.)
General business savvy (sales, marketing, support, industry-specific)
Client-side script debugging
Fiddler output analysis
Cascading Style Sheets
CSS behaviors (HTC files)
Object-oriented programming (OOP)
.NET framework
ASP.NET (page development and Web Services)
Relational database concepts
SQL Server administration
SQL language
SQL clustering
T-SQL development / stored procedures
SQL Reporting Services
Windows Server 2003 / 2008
IIS configuration
Windows Services
Active Directory
Server/network security
Microsoft Exchange
Microsoft MOM
Hardware deployment
TCP/IP (at least the basics)
Microsoft Office
Data Migration
Windows Workflow Foundation
Windows Communication Framework
Debugging (client-side, .NET, SQL)
Systems Integration (messaging, BizTalk, etc.)
Load balancing
Web farms
High-availability (HA) system architecture
ActiveX / COM
Visual Studio 2010 (Added this one and the skills below in January 2010)...
.NET Framework 4.0
C# 4.0
SQL Server 2008
SharePoint 2010
JQuery and other JavaScript libraries
Microsoft Azure

In reading this list again, it's understandable why SaaS is catching on! That's a lot to know -- and to keep up on on a regular basis.

Still, think about the trade-offs of moving to a SaaS environment. If you really want your information technology to fit your business and not the other way around then it's often worth hiring people who can (and enjoy) working with the technologies noted above. For some reason, I'm one of those. Am I insane? Perhaps. But getting all of those pieces working smoothly and tailoring solutions to a business is very rewarding. And if my Dynamics CRM clients are seeing a return on their investment then this is a win for everyone involved.

Now, please excuse me. I haven't had a chance to crack the seal on my Silverlight Unleashed book yet so I have some reading to do...

Monday, June 9, 2008

An easy way to debug client-side code

On a recent project CRM 4.0), I was asked to revise the default behaviour of the "Convert Activity... To Case" option on the E-mail form. The client did not want the modal dialog box to appear (the one prompting for the Customer and Subject) and wanted instead to set default values in code. The business purpose for the change was to increase productivity and avoid incorrect data-entry by their 20+ users, who use that feature several times each day.

Below is a step-by-step process for making this change.

Note: Since this example requires a change to a core CRM js file, Microsoft considers this an "unsupported" customization.

In order to debug the "To Case" command (outlined below) I loaded my favorite IE browser add-in development tool... IE WebDeveloper. (See my previous blogs about this product.)

Using IE WebDeveloper, I was able to determine that the To Case menu option calls the function convertToCase with a parameter of 4202.

The screenshot below shows the "To Case" menu option (in the HTML DOM) highlighted on the left and the JScript function outlined on the right.

To start debugging the convertToCase(4202) function call, I used the Run Scripts feature of IE WebDeveloper to execute the JScript debugger statement along with the function, as shown below:

After clicking Run, I started debugging with Visual Studio 2008.

Since the script is running in the context of the current CRM web page, I was then able to step into the convertToCase function, which it turns out resides in \inetpub\wwwroot\_static\Activities\Activity.js.

Finally, I revised convertToCase (removed the code that opened the modal window) to my liking and debugged through the code a few more times to make sure my customization worked as planned.

The coolest part of using IE WebDeveloper to help out with this customization is not needing to place the debugger statement inside a script file -- I was able to start debugging immediately within the current page. This same technique can be used to fire onLoad, onChange, or any other window/document/element event. For example, to fire onLoad you can run this in the IE WebDeveloper:


Again, this lets you step through the onLoad script of any form without the need to place a debugger statement in the form code.

As another example, assume you want to fire the onClick message for a custom button added via ISV.Config and debug into the JScript that CRM constructs. Run this code in the IE WebDeveloper script window to start a debug session in Visual Studio:

var customButton = document.getElementById("ISV_New_4_GPInvoiceLookup").childNodes.item(0).childNodes.item(0).childNodes.item(1);
var evt = document.createEventObject();
customButton.fireEvent("onclick", evt);

Sunday, June 8, 2008

IE WebDeveloper

A while back I discovered a great browser add-in and development tool named IE WebDeveloper. Although there are some similar add-ins available that are free, it's worth the small price to get the extra features in this app.

Here's how I find myself using IE WebDeveloper while working on CRM 4.0 implementations:
  • Get the schema name of any attribute on a form.
  • Execute scripts (jscript/javascript) against the current page. Examples: fire the onLoad event for the page or onChange for any field, test your code on the live CRM form page (current DOM) before publishing it, manipulate the browser DOM interactively to test custom UI functionality, or write and run a script to list all "dirty" fields on a form.
  • View the script tied to any DOM element. I use this as a quick way to view the onChange code for fields.
  • Interactively change the content, attributes, and style for any DOM element. This is useful for placing custom elements on the page, such as an icon next to a field. My team did this recently to provide real-time duplicate checking for data entered into a field. Being able to place images on the form, nudge them around, etc. saved a lot of time and guesswork. (Of course, what I described was an "unsupported" customization.)
  • Get the id (Guid) of an entity listed in a grid.
  • Capture all window, document, and element events. I used this recently on a custom ASP.NET page (integrated into CRM) to write code to handle various mouse events.

Besides being able to easily browse up and down the page DOM, the second most useful feature of IE WebDeveloper is the ability to run scripts interactively against the current page. You can dynamically hide and show tabs, test field validation code, loop through elements to perform actions on them, and just about anything else you might need to do to interact with any screen in CRM. It really takes the guesswork out of how CRM pages are constructed and how to customize them.

As for other browser tools, I also use Instant Source for interactively browsing the page DOM and Fiddler to help with performance and troubleshooting.

Lastly, if you have a weekend (and hard drive) to fill and want to add to your development tool collection, then it's hard to find a larger collection of dev tools than Scott Hanselman's "ultimate tools" page.

A wealth of knowledge... and how to keep up.

If you implement Dynamics CRM full-time like I do, you want to be sure to keep up on the latest SDK releases, sample code, tools, tips, tricks, etc. One app that makes this easier is Copernic Agent Pro.

With Copernic's web page tracking feature, you enter links for the pages you want to track, set up the tracking schedule, and it will send an e-mail to you with the pages that were updated. It even highlights the content that's new or updated.

The app's main feature is to search for web content, filter-out missing pages and those that don't contain the words (or Boolean expression) that you specify, and to highlight the search "hits".

In my next blog I'll list the 40+ blog sites and general MSCRM sites that I have Copernic tracking for me each day. Now, if only it would consolidate all blog updates into one Word doc or PDF and load it to my Amazon Kindle for my daily commute... panacea!