You’re offline. This is a read only version of the page.
Hi,
I am trying to create a model based application with the following scenario
- The account has many contacts, Contacts has many accounts
- Contacts must have at least one account
- Contact can have different roles/job in a different account.
For example: John works in Hospital A, as well as in Hospital B. John, is a consultant, as well as an Owner in Hospital A and John, is also the therapist in Hospital B. John must be associated with at one hospital.
Under the above scenario, can you help in how to create entities and how to implement in the model-based application?
Hi @TimRohr,
Thanks for the response. I have done something like RoleProfile. I used three entities Account, Contact & AccountContact
Account 1-N AccountContact
Contact 1-N AccountContact
In my scenario, I will have for example; a contact called Jack who can work for two accounts Account A and Account B. He can have multiple roles for an account, lets say "Cleaner", "Driver" for Account A and just "Driver" for Account B. Now, the problem when adding a contact, I must be linked with an account via AccountContact entity.
I thought of implementing business process flow, wherein Stage 1 he adds a contact and stage two add an account and his role for the following account in AccountContact Entity. But the problem is relationships can't be defined as mandatory.
I just did an app very similar to this.
From a data normalization perspective, you will have at least 3 entities (to cover what you explained):
Accounts
Contacts
RoleProfiles
Accounts will relate 1:N with RoleProfiles.
Contacts will relate 1:N with RoleProfiles.
This means that every Account could have a number of RoleProfiles, each of which would be associated with a particular Contact. Make sense so far?
Create those by using LookUp fields in the entities.
Now here are the caveats:
1) Do you have a finite list of functions/duties that a Contact can perform for a particular Account? For instance:
Doctor, Therapist, Admin, Nurse
If so, your RoleProfile can be set up to be Yes/No fields for each of the defined functions. If Contact1 fulfills the functions of both Doctor and Admin, turn them both to Yes ('true').
If NOT... if your list could expand or come to have more functions defined that you would want to track (like deciding you wanted to track, "Purchasing" at some point in the future), you might want to consider limiting the RoleProfile entity to be just 1 function at a time (tracking Account, Contact, and Function), and producing multiple records for every Account-Contact combination. However, my experience is that unless there is a very dynamic list of functions, changing all the time, or specific information about the functions themselves that you need to track on an individual basis (ie, Contact1 at Hospital1 fulfills the function of Purchasing with a budget of $10,000 and ownership over office supplies and technology, but not medical supplies), then a flat RoleProfile record with multiple yes/no fields works fine.
2) Your requirement that a Contact must have at least one Account (which, in the parlance of our entity set, would be a RoleProfile)...
In this scenario, a Contact must be written before a RoleProfile can be written (since the latter will lookup the former). So, if this is an absolute requirement that a Contact MUST have a RoleProfile, you could set up your "New Contact" form to include a "New RoleProfile" section, as well, and only write the record if you have ALL of the information you need to write both a new Contact and a new RoleProfile. This might take two forms on the same screen, and you'd have to prep each as New and submit them in turn in your Submit button. (I have not done that, but I don't see why you couldn't do it.) You would also need an alert if the Contact were to have his/her last RoleProfile deleted from them.
On the other hand, if it is just a general guideline that any given Contact will be PRIMARILY associated with one given Account, you could just include that as a Lookup field in the Contact entity drawing from the Account entity. Each Contact would be primarily associated with one Account, but each Account might have many Contacts for whom that Account is their "primary association."
Note that in this case, this association is a logically different thing from RoleProfiles. Contact1 could have a PrimaryAccountAssociation of Hospital1, but there would be no RoleProfile definition for this. You would have to create a RoleProfile for Contact1 at Hospital1 that you could use wherever you would be using RoleProfiles. Also, should you delete the RoleProfile that represented Contact1 at Hospital1, you could end up in a situation where the PrimaryAccountAssociation still pointed to an Account for which that Contact did not have a RoleProfile.
As for implementation...
Create drill paths (or search option paths)... you can drill down on the Account to find associated RoleProfiles, and from there examine the functions fulfilled by that person for that account... and then go to the person, etc. Or you can drill down from the person and see all of their associated RoleProfiles, see the functions they fulfill, and go from there to the Account associated. Or you can look up "For [this Account], who fulfills [x] job function?" And return all of the RoleProfiles that meet that criteria.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
Share
Report
All responses (
Answers (
669
