CRM in the clouds
Hi, Habr!
In this article, we want to share our experience with the Microsoft Dymanics CRM 2013 Online software product - for what and how it can be used, possible problems of typical deployment, typical functionality - advantages, disadvantages and ways to solve problems at the lowest cost.
All the stated theses are based on the practical experience of implementing the system with a specific customer. Therefore, we tried to omit the description of typical tasks, and concentrate on the nuances that most companies may encounter when setting up the system and adapting to the requirements of the business. So…
When the cloud solution option becomes attractive (our subjective opinion):
As a result, we can get rich functionality “out of the box” with the possibility of its expansion and adaptation to the requirements of the business. It makes no sense to dwell on the description of the functionality and possibilities, all the information in excess is available in open sources of information.
Further we configure users. And we have two options: either we make CRM Online users in the cloud manually, or we set up integration with the existing AD domain. Separately, focus on integration with Active Directory.
')
The advantage of using AD integration is obvious. From the point of view of administration, we will have a single mechanism for managing users, common logins and passwords, we will not have to maintain a separate set of accounts in the domain and in CRM. If the user leaves, his access is blocked to all information resources of the company, including CRM. It is also possible to use the same domain policies, such as password complexity, number of incorrect attempts, etc. But, to configure the integration will require additional resources:
Our customer made a simpler option with AD synchronization through DirSync.
Working with e-mail in CRM Online and CRM On-Premises is a topic for a separate article. Now we note that the most complete mail in CRM Online integrates with cloud services Exchange Online, Gmail, Yahoo. In the case of using external connectors (Server Side Synchronization), there are limitations in the process of synchronizing the sent mail from CRM Online and user mailboxes. In our case, mail synchronization through an external connector is used.
Access is configured, you can start working. But, as a rule, it is required (or would like) to transfer historical data to a new system. In general, everything is simple here - CRM supports the main open data formats, you can also upload templates in XML format to prepare the data for download.
What could be the pitfalls here? Consider a practical business case.
In CRM organized reference books of geographical concepts. The implementation was made through the creation of new entities of the system according to the principle: “Federal District” - “Subject of the Russian Federation” - “Locality”. That is, the structure of hierarchical directories is organized. Such a solution (perhaps not perfect) is quite convenient from the user's point of view and data administration. It will allow further expansion of analytics by cities (for example, population size, consolidation of personal responsibility, classification by interests, etc.).
In the templates prepared by CRM, the data entered and successfully loaded into the system. Moving on.
Now we are preparing data on the company's customers, again, based on CRM templates. The data for each client must contain information on its geographical affiliation (federal district, subject of the Russian Federation, locality). We start the download.
Here we are faced with the first problem - the system gives import errors (link to duplicate data). What is the matter?
And the fact is that there are a lot of settlements with the same names in various regions of the Russian Federation. It turns out that despite the fact that we organized a hierarchical structure of reference books and when preparing a template with data for download, we indicated in which subject of the Russian Federation there is a particular settlement with the same name. Since we have many cities with identical names, CRM cannot load such data.
Way out? At the discretion of the company there may be several:
What way to choose, each company chooses itself. The main thing is to be aware of a potential problem and to take into account possible risks at the work planning stage.
By the way, a similar problem may arise when importing organizations and contacts : there may be a conflict between the "Phone" field in the organization and the "Business phone" field of the contact (CRM does not allow the same values ​​in this field). Output - or different values ​​of phone numbers, or the use of their own fields (attributes).
What else can you encounter, moving further, during the initial configuration of the main sections of the system?
Consider the following practical business case on the example of a company that manufactures and sells shoes or clothing. As a rule, such companies are accustomed to operating approximately with such a minimum set of characteristics of a commodity unit:
Everything is fine and logical. But, unfortunately, in the future we will understand that we simply cannot use the standard functionality for the formation of commercial offers, orders, invoices.
The fact is that when choosing products for the specification of a document, we will be available to identify it only with the name field. Thus, we will see a list of identical names of commodity items (article, color, size, etc. - not available). Modifying the standard functionality of working with the specification is quite laborious; besides, it will be necessary to modify separately for each section (a possible deal, commercial offer, order, invoice).
A variant that requires much less cost and more universal is the creation of a js-script that is registered in the properties of the form.
Additionally, we enter another field in the product card, where we will write down its actual name, and rename the “name” system field to “full name”. The principle of the script is as follows (for example): it reads information from the “name”, “color”, “size” fields and automatically writes data into the “full name” field through a separator (space, comma). Thus, we automatically receive the unique name of the item in the form of “Shoes, black, 42 ​​shoes”. This value will be automatically displayed in standard CRM specifications.
A function like string.format is well suited for creating such a script; it accepts a mask in the .Net format.
After connecting this function to the solution, you can write a small wrapper that accepts the format and the list of fields, calculates their values ​​and writes the formatted result in the desired field.
As you can see here
'name' is the name of the field entity name
'{0} {1} {2}' - a mask connecting 3 lines through spaces
['etrnova_fullname', 'etrnova_colour', 'size'] - the names of the fields that are substituted into the mask.
The result is achieved. Perhaps the solution is not perfect, but it is easy and quick. Moreover, this mechanism of forming a composite field can be further applied in other sections of the system (if necessary).
As you know, in Microsoft Dymanics CRM 2013 now all objects can now include pictures (photos).
But there are limitations:
If such restrictions do not affect the “Contact” object, for example, a picture of a partner, then the practical application for other objects becomes highly conditional (limitations on the number and small size).
But in real life, there is often a need to work with images without limiting their number and size , for example:
Is it possible to implement such functionality , in what ways and at what costs? Let's consider.
There may be several solutions, each with its own shortcomings. You can make a child entity in which there is a “photo” field. Field of which, using the JavaScript API, display photos in a list. There is an excellent commercial solution that uses this approach. The disadvantage of the approach is the mentioned restriction on the size of photos. To try to bypass it, you can write a photo in a text field in Base64 format. Of course, this will lead to excessive consumption of space, however, if there are not very many photographs, the solution is quite acceptable.
In this case, there will be no limit on the size of the image, but there will be a limit on the size of the file with the photo ~ 500kb; also photos can be significantly larger than 144x144.
And finally, if you want to completely circumvent this limitation, you can store photos in a third-party system and write an interface that displays their list inside the entity. Such a solution, of course, is much more difficult in terms of installation and support, but in some cases it is justified.
In our case, the second option turned out to be the most preferable because, on the one hand, it provides the ability to store images of sufficient size for our tasks, on the other hand, it is less difficult to deploy than the third one. To implement it, we create the Photo entity in it, we make stock fields ... EntityId, ... EntityType, ImageContent, on the form we implement an interface for displaying and editing a set of pictures, like the following:
Thus, it is possible to solve the problem and expand the functionality of the system. We think that there are many more business problems where this solution can be applied.
In most cases, the basic functionality for organizing work with organizations and contacts, which the system offers, is more than enough (taking into account possible additional settings for partitions using the system’s standard tools).
The only inconvenience that users often encounter is associated exclusively with the specifics of our country. It is not a secret for anybody that, for various reasons, the same company may have several legal entities. In this case, the contacts remain the same.
Unfortunately, the standard CRM functionality allows you to connect a contact with only one organization, and the use of the “parent organization” functionality is not always convenient, in particular, the link to the contact does not appear in the associated contact view in the organization, which is not always convenient for the end users to work.
Is it possible to easily get around this system flaw? Can.
In fact, the “contact” field will have to be left, perhaps renamed to “main contact”, and you can also make a Many-to-Many relationship between customers and contacts. On the form you need to add a special plate to the form to display editing contacts. The main contact will be used in the views, as well as, say, in the construction of graphs that do not support multiple links.
After this procedure, it becomes possible to select several organizations from the list when generating (editing) contact information.
Accordingly, the contact card will indicate which organizations it is associated with. And after saving the data, the specified contact will automatically appear in the associated view in each specified organization.
The standard CRM access rights system allows you to operate with access rights to information sections and records at the user, department, and organization level, as well as at the working group level. This system of managing user access rights in most cases is enough. However, in real life there are exceptions. An example is the company has regional managers who control transactions in the regions assigned to them. And in the regular structure of the company, all regional managers are in the same structural unit.
If you operate with regular means, then the solution will be as follows: it is necessary to introduce "artificial" staff units for distributing access rights to the records. This, on the one hand, will solve the problem without resorting to the services of technical specialists, but on the other hand, it will create a new problem - the company's full-time structure in CRM will differ from the actual one, plus the number of these artificially created units will be equal to the number of regional managers.
But there is another way to solve this problem, and the rights of access to the records will be distributed on the basis of information about which region the organization belongs to (interest, transaction). To do this, for a start, take a closer look at how the system of access rights in CRM is structured. Suppose a user is trying to access a certain type (for reading, for changes, etc.) to a certain record. Why can he get it? There are two options:
Thus, we can “share” each entry for the regional manager corresponding to the region of the entity. This is a simple job, and it is easy to automate it by writing a special plugin that will provide (or remove) general access when the field defining the region changes.
Pay attention to the section “type of relationship”. We see the items “Assign”, “Sharing”, etc., and for each of these actions you can determine the type of behavior. For example, choosing the “cascade” type of behavior for “Sharing”, we will get the following: if someone shares an entity, we will get access to the subsidiary too.
Of course, we want regional managers to have rights not only to the record, but also to all child records. To do this, set up a relationship:
So,
The product is arguably controversial and ambiguous: on the one hand, it allows for customization (UI, database structure, business processes) for business requirements by standard means, without resorting to programming (and this is definitely its strength and competitive advantage ). But on the other hand, this is also its “weakness” - the user is caught in the framework of this regular functionality, and further extensions of the functional are possible only with the help of technical specialists (that is, programming).
This statement is true for setting up the user interface, for business processes, and for the basic logic of the system.
As an out-of-the-box solution, a simple business solution can, in the case of complex business processes and business requirements that go beyond the basic functionality, unfortunately, can’t do without modifications, the only question is what price ...
In this article, we want to share our experience with the Microsoft Dymanics CRM 2013 Online software product - for what and how it can be used, possible problems of typical deployment, typical functionality - advantages, disadvantages and ways to solve problems at the lowest cost.
All the stated theses are based on the practical experience of implementing the system with a specific customer. Therefore, we tried to omit the description of typical tasks, and concentrate on the nuances that most companies may encounter when setting up the system and adapting to the requirements of the business. So…
Why the "cloud"?
When the cloud solution option becomes attractive (our subjective opinion):
- there is a need for a CRM system, but there is no clear vision of “what, why, and how”;
- the number of potential users of the system is quite small;
- there is no necessary infrastructure to deploy the solution;
- there is a desire to optimize the organization of the internal support system for a new solution;
- you need to minimize the financial costs of purchasing (supporting) a solution - everything is clear here - a trial period of 30 days, a low subscription cost, sufficiently preferential terms of payment (deferred payment).
As a result, we can get rich functionality “out of the box” with the possibility of its expansion and adaptation to the requirements of the business. It makes no sense to dwell on the description of the functionality and possibilities, all the information in excess is available in open sources of information.
Registered. What's next?
Further we configure users. And we have two options: either we make CRM Online users in the cloud manually, or we set up integration with the existing AD domain. Separately, focus on integration with Active Directory.
')
The advantage of using AD integration is obvious. From the point of view of administration, we will have a single mechanism for managing users, common logins and passwords, we will not have to maintain a separate set of accounts in the domain and in CRM. If the user leaves, his access is blocked to all information resources of the company, including CRM. It is also possible to use the same domain policies, such as password complexity, number of incorrect attempts, etc. But, to configure the integration will require additional resources:
- If you just want to synchronize, you will need a server in the domain with the DirSync software.
- If you want to organize single sign-on (Single Sign On), then you need an ADFS infrastructure.
Our customer made a simpler option with AD synchronization through DirSync.
More information about setting up synchronization with AD can be found on page.
Configure mail system.
Working with e-mail in CRM Online and CRM On-Premises is a topic for a separate article. Now we note that the most complete mail in CRM Online integrates with cloud services Exchange Online, Gmail, Yahoo. In the case of using external connectors (Server Side Synchronization), there are limitations in the process of synchronizing the sent mail from CRM Online and user mailboxes. In our case, mail synchronization through an external connector is used.
You can find out more about mail configuration here and here.
Loading initial data
Access is configured, you can start working. But, as a rule, it is required (or would like) to transfer historical data to a new system. In general, everything is simple here - CRM supports the main open data formats, you can also upload templates in XML format to prepare the data for download.
What could be the pitfalls here? Consider a practical business case.
In CRM organized reference books of geographical concepts. The implementation was made through the creation of new entities of the system according to the principle: “Federal District” - “Subject of the Russian Federation” - “Locality”. That is, the structure of hierarchical directories is organized. Such a solution (perhaps not perfect) is quite convenient from the user's point of view and data administration. It will allow further expansion of analytics by cities (for example, population size, consolidation of personal responsibility, classification by interests, etc.).
In the templates prepared by CRM, the data entered and successfully loaded into the system. Moving on.
Now we are preparing data on the company's customers, again, based on CRM templates. The data for each client must contain information on its geographical affiliation (federal district, subject of the Russian Federation, locality). We start the download.
Here we are faced with the first problem - the system gives import errors (link to duplicate data). What is the matter?
And the fact is that there are a lot of settlements with the same names in various regions of the Russian Federation. It turns out that despite the fact that we organized a hierarchical structure of reference books and when preparing a template with data for download, we indicated in which subject of the Russian Federation there is a particular settlement with the same name. Since we have many cities with identical names, CRM cannot load such data.
Way out? At the discretion of the company there may be several:
- another system of organizing reference information, for example, in the form of a single complex entity with all the necessary attributes, but, as practice shows, the organization of the “self” connection is not the best option;
- organization of data download using scripts (requires the involvement of relevant technical specialists);
- change of the name of settlements: each has a unique name; after successful import, you can rename it back without losing information (this is an additional amount of work on the subsequent correction of data).
What way to choose, each company chooses itself. The main thing is to be aware of a potential problem and to take into account possible risks at the work planning stage.
By the way, a similar problem may arise when importing organizations and contacts : there may be a conflict between the "Phone" field in the organization and the "Business phone" field of the contact (CRM does not allow the same values ​​in this field). Output - or different values ​​of phone numbers, or the use of their own fields (attributes).
Refinement of the main functionality of CRM (Products)
What else can you encounter, moving further, during the initial configuration of the main sections of the system?
Consider the following practical business case on the example of a company that manufactures and sells shoes or clothing. As a rule, such companies are accustomed to operating approximately with such a minimum set of characteristics of a commodity unit:
- name;
- Colour;
- the size;
- vendor code;
- season;
| vendor code | name | Colour | the size | season |
| 000142 | Shoes | the black | 42 | autumn |
| 000143 | Shoes | the black | 43 | autumn |
Everything is fine and logical. But, unfortunately, in the future we will understand that we simply cannot use the standard functionality for the formation of commercial offers, orders, invoices.
The fact is that when choosing products for the specification of a document, we will be available to identify it only with the name field. Thus, we will see a list of identical names of commodity items (article, color, size, etc. - not available). Modifying the standard functionality of working with the specification is quite laborious; besides, it will be necessary to modify separately for each section (a possible deal, commercial offer, order, invoice).
A variant that requires much less cost and more universal is the creation of a js-script that is registered in the properties of the form.
Additionally, we enter another field in the product card, where we will write down its actual name, and rename the “name” system field to “full name”. The principle of the script is as follows (for example): it reads information from the “name”, “color”, “size” fields and automatically writes data into the “full name” field through a separator (space, comma). Thus, we automatically receive the unique name of the item in the form of “Shoes, black, 42 ​​shoes”. This value will be automatically displayed in standard CRM specifications.
A function like string.format is well suited for creating such a script; it accepts a mask in the .Net format.
After connecting this function to the solution, you can write a small wrapper that accepts the format and the list of fields, calculates their values ​​and writes the formatted result in the desired field.
function calcName(name, mask, params) { var name = Xrm.Page.getAttribute(name); var vals = []; for (param in params) { var val = Xrm.Page.getAttribute(params[param]); val = val != null ? val.getValue() : ""; vals.push(val != null ? val : ""); } name.setValue(mask.format.apply(mask, vals)); } . As you can see here
'name' is the name of the field entity name
'{0} {1} {2}' - a mask connecting 3 lines through spaces
['etrnova_fullname', 'etrnova_colour', 'size'] - the names of the fields that are substituted into the mask.
The result is achieved. Perhaps the solution is not perfect, but it is easy and quick. Moreover, this mechanism of forming a composite field can be further applied in other sections of the system (if necessary).
Photos in CRM
As you know, in Microsoft Dymanics CRM 2013 now all objects can now include pictures (photos).
But there are limitations:
- they are stored in the field with the type of "image";
- displayed only in the upper left corner of the form;
- there can be only one image field per object;
- image size is limited to 144x144px.
If such restrictions do not affect the “Contact” object, for example, a picture of a partner, then the practical application for other objects becomes highly conditional (limitations on the number and small size).
But in real life, there is often a need to work with images without limiting their number and size , for example:
- product cards (product images);
- customers (merchandising).
Is it possible to implement such functionality , in what ways and at what costs? Let's consider.
There may be several solutions, each with its own shortcomings. You can make a child entity in which there is a “photo” field. Field of which, using the JavaScript API, display photos in a list. There is an excellent commercial solution that uses this approach. The disadvantage of the approach is the mentioned restriction on the size of photos. To try to bypass it, you can write a photo in a text field in Base64 format. Of course, this will lead to excessive consumption of space, however, if there are not very many photographs, the solution is quite acceptable.
In this case, there will be no limit on the size of the image, but there will be a limit on the size of the file with the photo ~ 500kb; also photos can be significantly larger than 144x144.
And finally, if you want to completely circumvent this limitation, you can store photos in a third-party system and write an interface that displays their list inside the entity. Such a solution, of course, is much more difficult in terms of installation and support, but in some cases it is justified.
In our case, the second option turned out to be the most preferable because, on the one hand, it provides the ability to store images of sufficient size for our tasks, on the other hand, it is less difficult to deploy than the third one. To implement it, we create the Photo entity in it, we make stock fields ... EntityId, ... EntityType, ImageContent, on the form we implement an interface for displaying and editing a set of pictures, like the following:
Thus, it is possible to solve the problem and expand the functionality of the system. We think that there are many more business problems where this solution can be applied.
Organizations and contacts
In most cases, the basic functionality for organizing work with organizations and contacts, which the system offers, is more than enough (taking into account possible additional settings for partitions using the system’s standard tools).
The only inconvenience that users often encounter is associated exclusively with the specifics of our country. It is not a secret for anybody that, for various reasons, the same company may have several legal entities. In this case, the contacts remain the same.
Unfortunately, the standard CRM functionality allows you to connect a contact with only one organization, and the use of the “parent organization” functionality is not always convenient, in particular, the link to the contact does not appear in the associated contact view in the organization, which is not always convenient for the end users to work.
Is it possible to easily get around this system flaw? Can.
In fact, the “contact” field will have to be left, perhaps renamed to “main contact”, and you can also make a Many-to-Many relationship between customers and contacts. On the form you need to add a special plate to the form to display editing contacts. The main contact will be used in the views, as well as, say, in the construction of graphs that do not support multiple links.
After this procedure, it becomes possible to select several organizations from the list when generating (editing) contact information.
Accordingly, the contact card will indicate which organizations it is associated with. And after saving the data, the specified contact will automatically appear in the associated view in each specified organization.
Revision of access rights
The standard CRM access rights system allows you to operate with access rights to information sections and records at the user, department, and organization level, as well as at the working group level. This system of managing user access rights in most cases is enough. However, in real life there are exceptions. An example is the company has regional managers who control transactions in the regions assigned to them. And in the regular structure of the company, all regional managers are in the same structural unit.
If you operate with regular means, then the solution will be as follows: it is necessary to introduce "artificial" staff units for distributing access rights to the records. This, on the one hand, will solve the problem without resorting to the services of technical specialists, but on the other hand, it will create a new problem - the company's full-time structure in CRM will differ from the actual one, plus the number of these artificially created units will be equal to the number of regional managers.
But there is another way to solve this problem, and the rights of access to the records will be distributed on the basis of information about which region the organization belongs to (interest, transaction). To do this, for a start, take a closer look at how the system of access rights in CRM is structured. Suppose a user is trying to access a certain type (for reading, for changes, etc.) to a certain record. Why can he get it? There are two options:
- Among user roles there is one that allows you to get the required access to the entity.
- The user has access to it (“share”).
Thus, we can “share” each entry for the regional manager corresponding to the region of the entity. This is a simple job, and it is easy to automate it by writing a special plugin that will provide (or remove) general access when the field defining the region changes.
Pay attention to the section “type of relationship”. We see the items “Assign”, “Sharing”, etc., and for each of these actions you can determine the type of behavior. For example, choosing the “cascade” type of behavior for “Sharing”, we will get the following: if someone shares an entity, we will get access to the subsidiary too.
Of course, we want regional managers to have rights not only to the record, but also to all child records. To do this, set up a relationship:
Conclusion
So,
- Microsoft Dynamics CRM 2013 Online out of the box is a powerful and sufficient tool.
- Microsoft Dynamics CRM 2013 Online has the simplicity and flexibility to customize business processes and system objects without programming.
- Expansion of the functionality of Microsoft Dynamics CRM 2013 Online, which cannot be made using the settings, is solved quickly and easily using programming tools.
- The technologies and architecture of the solution used allow the system to be adapted to the specific specifics of the activity of almost any company and integrate the solution with existing information systems.
The product is arguably controversial and ambiguous: on the one hand, it allows for customization (UI, database structure, business processes) for business requirements by standard means, without resorting to programming (and this is definitely its strength and competitive advantage ). But on the other hand, this is also its “weakness” - the user is caught in the framework of this regular functionality, and further extensions of the functional are possible only with the help of technical specialists (that is, programming).
This statement is true for setting up the user interface, for business processes, and for the basic logic of the system.
As an out-of-the-box solution, a simple business solution can, in the case of complex business processes and business requirements that go beyond the basic functionality, unfortunately, can’t do without modifications, the only question is what price ...
Source: https://habr.com/ru/post/237841/
All Articles