locked
Am I doing this right? RRS feed

  • Question

  • OK, let me try to explain the scenario, my employer deals with an organization that has divisions in several cities in several states. Each of the divisions has 200-300 users. We currently use the CRM to keep track of the enrollment process. The way I have been doing it so far has been to make a solution for the division, with forms, fields, dashboards, etc., and then accessing the dashboards via Outlook and the web. Am I going about it the right way? I ask because as we add new divisions, there will be several dashboards and it could get unruly. Thanks for any insight!
    Tuesday, June 3, 2014 6:40 PM

Answers

  • Hi,

    What you are doing isn't necessarily incorrect. It depends on how different each division is in terms of process and data requirements. I wouldn't create new forms simply because a new division is added if they can share forms of existing divisions although the up side of adding new ones is you can bespoke the division's forms without impacting other divisions and it will help user adoption to give the users fields & labels that they are familiar with. If two divisions have the same requirements then try to standardise your forms and re-use fields to lessen your administrative overhead. I don't know how many divisions and forms/fields you envisage but keep in mind field limits (1024 officially but in practice you'll hit issues around 800 depending on field types).

    You also need to balance the above with your ability to support the application. You can't selectively export forms when building a solution release so all forms will get updated for an entity included in your solution. With lots of forms, if you have multiple divisions requesting changes, you need to have a robust release process in place. Another consideration is the overhead you'll face when CRM is upgraded in future. If you have upgraded from CRM2011 to CRM2013, you may be familiar with the 2 stage form upgrade procedure. This second stage of re-creating the form and importing fields/sections/tabs from an old style form although not mandatory, did enable you to leverage new controls introduced in CRM2013. One stipulation of moving to the next major release will be to perform this second stage upgrade of all your forms before the upgrade will be permitted. Read this for more info http://blogs.msdn.com/b/crm/archive/2014/05/14/important-information-about-supported-configurations-in-the-next-major-release-for-crm.aspx

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Tuesday, June 3, 2014 9:39 PM
    Answerer

All replies

  • Hi,

    What you are doing isn't necessarily incorrect. It depends on how different each division is in terms of process and data requirements. I wouldn't create new forms simply because a new division is added if they can share forms of existing divisions although the up side of adding new ones is you can bespoke the division's forms without impacting other divisions and it will help user adoption to give the users fields & labels that they are familiar with. If two divisions have the same requirements then try to standardise your forms and re-use fields to lessen your administrative overhead. I don't know how many divisions and forms/fields you envisage but keep in mind field limits (1024 officially but in practice you'll hit issues around 800 depending on field types).

    You also need to balance the above with your ability to support the application. You can't selectively export forms when building a solution release so all forms will get updated for an entity included in your solution. With lots of forms, if you have multiple divisions requesting changes, you need to have a robust release process in place. Another consideration is the overhead you'll face when CRM is upgraded in future. If you have upgraded from CRM2011 to CRM2013, you may be familiar with the 2 stage form upgrade procedure. This second stage of re-creating the form and importing fields/sections/tabs from an old style form although not mandatory, did enable you to leverage new controls introduced in CRM2013. One stipulation of moving to the next major release will be to perform this second stage upgrade of all your forms before the upgrade will be permitted. Read this for more info http://blogs.msdn.com/b/crm/archive/2014/05/14/important-information-about-supported-configurations-in-the-next-major-release-for-crm.aspx

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Tuesday, June 3, 2014 9:39 PM
    Answerer
  • OK, that's VERY helpful! Didn't know about the field limit. SO let me ask you this. Let's say I have a database to import, they have their own field names, for example, for street address they have "Local_Street_Address". Would I make a new field named the way they have it or would I create a field named "Street1" that I could map it to and also map any other subsequent fields in other databases with different names for street address? Does that make sense? And might I add that so far this forum has been AWESOME at helping me get my feet wet with CRM. If it wasn't for people like you I would be TOTALLY lost!
    Wednesday, June 4, 2014 1:55 PM
  • Hi,

    If you have a 'new database to import' you would go through a process of field mapping rather than creating new fields verbatim. You should avoid ever having 2 fields that serve the same purpose. Not only is it bad design but it will make reporting a nightmare.

    Thanks for the kind words, it's nice to get comments like that and not just do this for the 10 points 'answer' mark (or 5 points helpful vote ;-) )

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Thursday, June 5, 2014 6:45 AM
    Answerer
  • So you wouldn't suggest using fields like City, Street, Zip between different divisions? Or you wouldn't suggest having unique fields every time for those, like div1_street, div2_street, etc...
    Thursday, June 5, 2014 2:46 PM
  • I see no reason why you would want to have 2 or more fields to hold the same piece of data. Standardise where possible.

    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Thursday, June 5, 2014 9:40 PM
    Answerer
  • Hi,

    What you are doing isn't necessarily incorrect. It depends on how different each division is in terms of process and data requirements. I wouldn't create new forms simply because a new division is added if they can share forms of existing divisions although the up side of adding new ones is you can bespoke the division's forms without impacting other divisions and it will help user adoption to give the users fields & labels that they are familiar with. If two divisions have the same requirements then try to standardise your forms and re-use fields to lessen your administrative overhead. I don't know how many divisions and forms/fields you envisage but keep in mind field limits (1024 officially but in practice you'll hit issues around 800 depending on field types).

    You also need to balance the above with your ability to support the application. You can't selectively export forms when building a solution release so all forms will get updated for an entity included in your solution. With lots of forms, if you have multiple divisions requesting changes, you need to have a robust release process in place. Another consideration is the overhead you'll face when CRM is upgraded in future. If you have upgraded from CRM2011 to CRM2013, you may be familiar with the 2 stage form upgrade procedure. This second stage of re-creating the form and importing fields/sections/tabs from an old style form although not mandatory, did enable you to leverage new controls introduced in CRM2013. One stipulation of moving to the next major release will be to perform this second stage upgrade of all your forms before the upgrade will be permitted. Read this for more info http://blogs.msdn.com/b/crm/archive/2014/05/14/important-information-about-supported-configurations-in-the-next-major-release-for-crm.aspx

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    When you say 1024 fields, is that per solution, per entity or per form?
    Tuesday, July 8, 2014 12:50 PM
  • Per entity. As I said, you won't get anywhere near that before hitting issues. Another thing to consider is Microsoft tend to add new system fields with each major release so you really don't want to go near the limit else you'll end up needing to delete fields in order to upgrade in future.

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Tuesday, July 8, 2014 2:57 PM
    Answerer
  • Per entity. As I said, you won't get anywhere near that before hitting issues. Another thing to consider is Microsoft tend to add new system fields with each major release so you really don't want to go near the limit else you'll end up needing to delete fields in order to upgrade in future.

    Rob


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Gotcha. I revisited this question because of a new project I have, maybe you could give me some pointers. Here is the thread. Any advice you could give would be MUCH appreciated!
    Tuesday, July 8, 2014 3:11 PM