About a year ago Jon White’s article concerning a CRM Online Non-Interactive user type was posted on the CRM Team blog. I thought I’d add some additional information I found last week.
But first, a bit of background from Jon’s article:
A non-interactive user is a user account in Microsoft Dynamics CRM Online that can access the system but only via the web service layer. Essentially, that user can not use the user interface. Service accounts are used to access CRM Online using the service to service model. A service account is a non-interactive user account with the proxy role assigned to it. Microsoft Dynamics Online allows 5 free non-interactive user accounts. To make the user account a non-interactive account, you need to change the access mode. The access attribute is not visible in the UI by default. The attribute is “access mode�, you can either customize the form to show it, or manipulate it by an SDK call. Setting the access mode to non-interactive simultaneously frees up a license and prevents that identity from logging in interactively.
He goes on to tell you how to add the Access Mode field to the System User Entity form so that this field can be changed by the administrator.
You may also find it useful to put the Access Mode on the Active Users View, so that it displays when you are reviewing your user list:
Interesting Observation
Last week I was discussing non-interactive users with a colleague when I noticed a rather interesting situation: If you are out of user licenses for CRM Online you can’t create a non-interactive user through the CRM user interface. Curious, but understandable.
In a nutshell, the New User wizard will inform you that you are out of licenses and not allow you to continue.
You can circumvent the issue by performing these steps:
- Temporarily disable a user
- Create a new user and change their Access Mode setting to Non-Interactive
- Re-enable the user disabled in step 1.
That should do it.
Programmatic User Creation
Nothing, however, will stop you from creating a user programmatically. You just need to supply the proper values. Here’s some sample code:
systemuser user = new systemuser(); user.accessmode = new Picklist(SystemUserAccessMode.NonInteractive); user.firstname = "system"; user.lastname = "integration"; user.businessunitid = new Lookup("businessunit", new Guid("{C9694BD7-C0C4-DE11-B95D-02BF0A0679DB}")); service.Create(user);
As you can see, you only need four properties:
Access Mode
In this case, we’re going to supply NonInteractive as the value, since that is the purpose of our discussion.
First Name
First name of the user.
Last Name
Last name of the user
Business Unit ID
This is the ID of the business unit the user belongs to.
Calling the CrmService.Create method to actually create the user.
Afterwards, any connection that you need to make to CRM Online can use the new non-interactive user instead of a fully-licensed person.
Different companies treat leads differently depending on their business model and how they obtain the information for the company or person in question. While there is no absolute right or wrong way to do things, I have recently seen some less than optimal CRM implementations that could have probably have used a little more up-front discussion about business processes and customer acquisition.
So what is a lead anyway?
Well, opinions will vary, but in a nutshell, a lead is someone you don’t know, but you have enough information to locate and start a discussion with. This could be a little as a name and a phone number, an email, and maybe a company name.
An example of a lead is a name on a list that you purchased from a company like InfoUSA, the local chamber of commerce, etc.
Again, basically people you don’t know.
Other types of leads
There are many sales strategies in existence as there are people using them. You may have heard, seen, or used the following categories for potential customers:
- Lead
- Prospect
- Suspect
These can be used in a variety of ways, depending on your sales strategy or system.
How does Microsoft Dynamics CRM handle leads?
Dynamics CRM has three categories for people and companies:
Lead
Is a person that may or may not be associated with a company. The personal and company details are interrelated and can’t be associated with other companies or contacts.
Contact
Is a person that, again, may or may not be associated with a company. Contacts can be linked to other contacts.
Account
Is a company. The company can have an unlimited number of contacts and be associated with other companies.
The standard lead conversion process
If you purchase a list of names, those names can be imported into the CRM Lead entity and worked through your sales process until you reach a point where they can be converted into an Account and/or a Contact.
The conversion process automatically links the newly created Account and Contract records together and also creates a reference in both that points back to the originating Lead.
Other processes
But, nothing in the design of Dynamics CRM makes you follow this model and I have many customers who do not.
Many customers ignore the Lead entity entirely and just use Accounts and Contacts. The reasons vary, but in many cases, the sales process involves quite a period of time and there are multiple in involved on the customer-side of the equation. Also, some people do not purchase lists of unknown individuals from data providers but rather start off with at least some type of personal connection with the individual.
As mentioned above, Leads are a single contact at a single company. Once you demonstrate the requirement to record information for two contacts, you have exceeded the design for the Lead entity and must move forward to using an Account with multiple Contacts. Rather than spend time working with a Lead, many customers just start at the Account/Contact level.
How can I mix prospects and customers?
So for the moment let us call a prospective customer a Prospect and someone who has actually done business with us a Customer. If we have both of these type of records stored in the Account and Contact entities we might confuse who we are working with and who we want to work with.
Luckily, the Dynamics CRM product team has a built-in solutions for this problem.
Account
The Account entity has an attribute called Classification (accountclassificationcode) which is a picklist that we can use to define the type of company with are dealing with.
Contact
The Contact entity has a similar attribute called Relationship Type (customertypecode) which is also a picklist that we can use to define the person.
Making it work
You need to add the following entries to both of these picklists:
- Prospect
- Customer
Next, create new Views within each Entity to filter on the appropriate type. This will allow us to view a list of our Prospects and a list of our Customers.
When a connection to a new individual is established, via trade show, referral, etc., a new Account and Contact are created with the relevant information being entered into each record.
Conclusion
Well, that about covers it for today. I’d love to get feedback from other people describing how they use CRM to handle Leads, Prospects, and Customers. Just leave a comment on this article.
I ran into a fascinatingly irritating issue last weekend while moving a CRM 4.0 installation from Small Business Server 2003 to 2008.
It seems that the Exchange Migration Tool did not properly assign permissions to the Program Files folder where Exchange was installed. It did properly assign the permissions to the Exchange folder set, but not to the root Program Files folder.
Ordinarily this would not have been an issue if not for the fact that I was actually installing CRM into the same folder structure. Here is what happened:
The Problem
The problem surfaced in two separate ways:
- I was installing CRM using the default user of Network Service. This is also the user who would run the CRM Async Service. The installation failed with an access denied error message. It took me a while to figure out it was a permissions issue within the file system which I fixed by giving Network Service permissions to the Microsoft Dynamics CRM folder structure.
This was an incorrect solution.
- The second issue surfaced when I loaded the CRM web page and found none of the icons were visible and I was getting JavaScript errors.
After working with Microsoft and running a Fiddler trace, I finally tracked down the issue.
The Resolution
It turns out that the domain group Users had no access to the E:\Program Files folder structure which is where CRM was installed.
This surfaced initially because of the issue with Network Service not having access but it never occurred to me that an issue could be caused by a permission which is usually there.
I compared the permissions on the original SBS 2003 server against those of the SBS 2008 server to locate and correct the problem which was to give [domain]\Users read, execute, and list permissions on the folder structure.
Loading ...
