Hello everyone!
A quick bit of background: I am a moderately tech-competent employee with 0 experience with Dynamics or CRMs in general who has been handed the task of customizing a deployment of Dynamics CRM. While this experience is certainly teaching ME the value of paying implementation fees to have experts do this sort of thing, that decision is made at a much higher level and I have to do the best that I can.
I am reasonably confident that I will be able to make the actual adjustments through the Customize function, but I am not familiar enough with the capabilities and limitations of Dynamics to plan out a strategy that will meet our needs.
I'm having two major problems, first: we have three types of organizations we want to put into our CRM: customers, banks, and partners. Each customer works with a various selection of the banks, and a various selection of the partners. My initial thought is that it makes sense to implement these as separate entities, with customers taking the role of accounts and creating new ones for partners and banks. The guys upstairs want to have a way to track who works with whom, ideally a dynamically-populated list. This seems like it should be possible with N:N relationships, in the same way that opportunities are associated with accounts out of the box. However, while I've created a relationship between my test new entity and Accounts, I can't figure out how to actually make an association between test bank #1 and test account #1. So, the two questions here are: is this a reasonable way to go about implementing this? and if so, how can I make this new relationship appear on the "create relationship" drop-down on the account form?
The second problem: our company sells a number of different applications--and the different types of business have a different set of options. The bigwigs want to be able to select which apps each business currently uses, as well as record a variety of details on each independently, like monthly fees and renewal dates. I've considered two approaches, and they each have pretty major flaws.
First, I could define separate fields for each, like AppName1Yes/No, AppName1Contract, AppName1Fee, AppName2Yes/No, etc. and put every single one on the form, possibly adding business logic to hide the ones that are toggled as No. The drawback here is that it is extremely messy on the back end, require a the creation of a few hundred new fields, and would be relatively difficult to update if there are new apps introduced.
Possibility two would instead create general fields, like App#1Select (and be a picklist of a global list of all apps), App#1Contract, App#2Select, App#2Fee, etc. The problem I am having here is that I can't see a way to, say, query all clients who use AppName1, as it may be App#1 or App#8 for different clients (there is also a smaller issue that certain apps are used by multiple business types, but if they can't be reported on together it's not ideal but not a dealbreaker).
To sum up, I'm in way over my head. I am confident that if I know HOW to set this system up, I'll be able to figure out the implementation, but I just don't have the background with Dynamics customization to be able to design a solution. Any help or guidance anyone can provide would be greatly appreciated, and I apologize for asking for such complex help.
If anything is unclear, or you need more information, please ask!
All the best,
Befuddled.