Accedi
Microsoft.com
 
Microsoft
 
 
 
Microsoft >
> 
> 
How can we use Lead entity in 2 ways?

Odpowiedz How can we use Lead entity in 2 ways?

  • martedì 21 ottobre 2008 06:03
     
     
    Registrati per votare
    0

    Hello, everybody.

     

    We want to use Lead entity for 2 purposes:
    a) as a participant of the conference our client hold
    b) as a potential customer of our client

     

    How can we combine this 2 requirements?

     

    We can add some "Lead Type" attribute, that will define whether the Lead is a conference participant or a potential customer and:
    1. Dynamically show/hide necessary fields on the Lead form.
    2. Dynamically change requirement level of the fields on the Lead form.
    3. Create some different views for different types of Lead.
    4. Run different workflows depending on "Lead type" attribute value.

     

    But how can we split Read/Write priveleges of different Lead types between different group of users and business

    units depending on "Lead type" attribute value?
    We can Share separate group of records with defined work group of users, but it works for every single Lead record - that is hard for user to share hundreds of records.

     

    Also we can create some custom entity - but Lead has a lot of built-in relationships and functionality we need.
    For example, how can we add "Send Mail" functionality to a custom entity?

     

    Thanks a lot in advance.

     

     

     

Tutte le risposte

  • martedì 21 ottobre 2008 07:40
     
     Con risposta
    Registrati per votare
    0
    Hi Bakai,

    This is usually a difficult decision and almost an area where MS CRM falls short. We've had this request before where we wanted to create leads for different internal companies and had to create multiple tabs and related entities etc. In 4.0 this is somewhat resolved with multi-tenancy but in your case that doesn't neccesarily apply.

    The problem is that at this stage you may feel the solution is good enough but with time as each requirement changes the solution may become unmanageable. For example your advanced finds for a contact will show many fields that do not belong to that contact. To the end user this will become quite confusing. Mail Merge another example.

    As for going down the route of the custom entity, it mainly depends on how much you will be missing functionality wise if you use a custom entity.

    For example, you could relate a lead/contact to your 'participant' entity and make use of mappings to pre-populate the lead with data from the if and when you want to contact that person. You could write custom code to create an email off the 'participant' entity.

    Essentially I would recommend keeping it simple and trying to stick with as much out the box functionality as possible.

    Cheers,

    Karlo

    • Contrassegnato come risposta Bakai Madybaev mercoledì 18 marzo 2009 09:31
    •