Want to create new entity with 1:1 relationship to Account.. best practices?

(0) Share

Report

Posted on by Scott Galinac

155

The use case is that I'd like to add fields to the account entity, but these are not average 'account like' fields. Rather the information is a collection of values that are associated to a single account, but should be entered, managed, and audited as a group. I'm call this information "Extra Account Details."

I'd like these values shown native on the account page, but be read-only on the account form, with option (button) to "edit" them together in a form of their own. The modified by / modified date of this "Extra Account Details" should be independent of the main account page, since the user providing this extra data might be different from account owner. It's also important to track who provided "Extra Details" and when it was last updated, again.. independent of main account updates.

For example, I'd like to run reports to indicate "Extra Account Details" data is growing stale (last modified 6 months ago) and must be revisited by someone. I'd like change to main Account information to not reset this logic... and thus must keep Extra Account Details separate from standard account fields. Updating the address is NOT the same as updating this important "extra account details,"... so a new entity 'feels' like approach I should take.

I went into this approach by creating a new entity. Named the entity.... created fields... all that was good until until I reached the point of associating this custom entity to a single account.

I do no want 1:N nor N:1 since... again.. it's really an extension of the account fields. Also, these 1:N / N:1 relationship are navigable via menu options, and didn't seem possible to just show fields from "Extra Account Details" on the Account page. I've seen example online recommending to do BOTH 1:N / N:1 to simulate 1:1, but the user experience does not match my wants.

Also, 'connections' do not seem like correct approach either, since they are listed along side other listed connections (other contacts, for example). Again, I'd like these extra fields to look-and-feel like any other account field, with only exception they cannot be edited directly from the account form. Rather, user must actively go to an separate edit form to correctly track who is updating, with a new date stamp.

What am I missing? Is there no 'good' way to just make a new entity, indicate within CRM these two entities are 1:1 relationship, providing primary key fields between the two, and then native support for fields display?

Any thoughts, ideas or suggestions are welcome.

Otherwise, I'll have to just add more fields to account page, and lose some of my important data metrics against these new fields.

Thanks.

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (0)

Suggested answer

Parvez Ghumra 7 on at

Like (0)

Report

Hi Scott,

I would suggest the following approach:

1. Create 1:N relationship between your Account and 'Extra Account Details' entity.

2. Configure this relationship such that the navigation item is not displayed on the Account side of the relationship.

3. On the Account form, create a custom ribbon button (or button within a web resource) to launch a new 'Extra Account Account Details' record form associated with the parent Account record if one does not already exist, or edit the existing one if it exists.

4. Create a custom web resource to display the details of the 'Extra Account Details' record on the parent Account form in read-only mode.

Hope this helps.

Was this reply helpful? Yes No
Scott Galinac 155 on at

Like (0)

Report

Understood the concept... quick follow up.

Create 1:N .. got it.. along with configuring not to display. This way, while it's possible by data to have 1:N... I'll just build UI and functional to never allow creation of more than one details entity. Clear.

Question 1: How to I customize a web resource to launch directly to a entity (in this case, the single entity)? I have designed HTML with JScript to navigate to a outside URL.. but do I build a URL path with some UID of my detials entity? Link to an example is fine.

Question 2: Related to 1. What is HTML way to show fields from an entity on other side of this relationship? Understood it will not / will not be native field from Account entity, but best practice to display such 'child' fields? Again, link to good example is fine.

Thanks

Was this reply helpful? Yes No
Suggested answer

ScottDurow 21 on at

Like (0)

Report

This is a common issue when you want to logically partition your data across two entities - especially from a security perspective. The approach I take is to create a N:1 relationship from account to the extra entity(lookup field on account) and use a Realtime workflow to populate this lookup on create of account. You can then click on the lookup to edit the extra data and view it on the account form using an approach similar to crm2011lookuppreview.codeplex.com or in CRM2013 (when you upgrade!) using quick view forms - mahenderpal.wordpress.com/.../using-quick-view-form-in-ms-crm-2013

This is the other way round to Parvez's suggestion because you get the lookup on the account form which allows you to easily edit the record and can benefit from quick view forms.

Hope this helps,

Scott

Was this reply helpful? Yes No
Scott Galinac 155 on at

Like (0)

Report

Hm.. Quick Views look interesting.. and so does Realtime workflow.

Quick Views seem to allow quick way to show fields from entity X on a related entity Y. So... good.

I wonder if I can use a standard workflow to then create an instance of "Details" for every Account already in the system? Then set up a Realtime workflow to create a matching "Details" instance during any new account create by the users?

Also, curious how edit of detail will work? Quick View would just be a view into other entity, but how quickly launch into edit mode of the Detail type?

Need to move to 2013 before 2015 comes out. :-)

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (2)

Report

This is a common model that people need for all sorts of reasons, such as separating security role access to PII or financial data away from the parent Contact or Account.

I was also going to suggest a lookup and using Quick View form to achieve this.

To expand on that:

I would, as you suggest, use a Workflow to create the record for each Account when created (and run that retrospectively too).

In the Workflow, give the new Detail record a useful name such as "Details for Acme Plc", using the Account name as part of it. This will appear in a lookup field on the Account form, and give users a direct link to click to open that record and edit the details.

Add another workflow on change of Account Name to go and update this Detail record name (a good reason to use a N:1 here rather than 1:N)

I would make the lookup field on Account business required and read-only on the form, so a user cannot blank it out by mistake. Put it directly above the Quick View form, so it acts as a kind of title for that area.

I would still be tempted to add a 1:N from Account to Detail that is automatically filled in too, so you have a lookup in both directions. When looking at the Details record, it would then be trivial for a user to click on the lookup to get back to the parent Account. (again, make this lookup business required and read-only). As you mention, remove this from related entity navigation.

Plan so that users do not have to create these records, build them automatically. Then you should not need to worry about code to prevent them being created a second time. If you use a real time workflow to do this, you can get the workflow to run as the workflow owner (you), and therefore with your privileges. Then users won't need rights to create these records and you have one less thing to worry about.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Scott, How did you end up achieving the use case? Please share to help others on the forum.

regards,

harihar

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Quoting because it's been a while since this post...

[quote user="Adam Vero"]

...use a Workflow to create the record for each Account when created (and run that retrospectively too).

In the Workflow, give the new Detail record a useful name such as "Details for Acme Plc", using the Account name as part of it. This will appear in a lookup field on the Account form, and give users a direct link to click to open that record and edit the details.

Add another workflow on change of Account Name to go and update this Detail record name (a good reason to use a N:1 here rather than 1:N)

...I would still be tempted to add a 1:N from Account to Detail that is automatically filled in too, so you have a lookup in both directions.

[/quote]

I'm trying to implement this, but I'm getting confused about the relationships I need to establish. Yes, I'm a newbie.

The idea is to set up separate entities to handle account "details" that are specific to an account type to avoid over-populating the Account entity with all the attributes needed for several types of accounts.

In Account, there will be an *optional* lookup field for each of the types. Depending on the selection specified in the Business Type field (re-purposed for this), a record will be created in the appropriate details entity and the lookup field that corresponds to that account type will be updated to point to that record. In the end, each account record points to a record in one of the detail entities and that record points back to its related account. Hopefully this is not too confusing. :)

I believe what's needed are two workflows: 1) One that determines the account type and creates the detail record and, 2) One that that updates the corresponding lookup field on the Account entity with the ID of the newly created detail record.

To do this, which relationships do I need? Account 1:N Detail with Detail 1:N Account? Account N:1 Detail with Detail N:1 Account? Some other combination?

I'm running into things like the workflow dialog not showing the detail entities as related to Account so I can do an update.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

There is no such thing as an N:1 relationship really, it is simply a 1:N looked at from the other end. So you need Account 1:N Detail and Detail 1:N Account.

Trigger the workflow on the update of Business Type. Then create the details record, including filling in the lookup to the Account record.

After this point in the Workflow you can refer to this newly created record (the name to refer to it by will be the text entered as the description for the create step).

So fill in the lookup on the Account to point at the new record.

One thing that might make this model slightly simpler would be to have only one "Details" entity, and include on their a Business Type field to match the Account. Then you can use Business Rules, or more probably JavaScript to hide and reveal fields on the record according to the type. (With javascript you can hide whole sections or tabs at the same time, rather than having to list loads of fields)

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Your suggestions worked, thanks. The key clue was the referring to the newly created record. This is listed under "Local Values" in the "Look For" dropdown of the Form Assistance. I completely missed that, but it makes a lot of sense.

We considered the simpler design you recommended, but separate details entities give us a lot of flexibility, although at the cost of more complexity. Up front we get hit with having to figure out how we'll hook it all up, but after that it's the same functionality for N number different account types, without having to worry about JavaScript, and having the ability to do heavy customization without worrying about one account type's processing stepping over another.

Unfortunately, I can't mark the answer as "Verified" because it's not my post. :( I have a related question that I will be putting in a new post so I can verify it.

Was this reply helpful? Yes No
Martijn Vermunt on at

Like (1)

Report

"The key clue was the referring to the newly created record. This is listed under "Local Values" in the "Look For" dropdown of the Form Assistance."

Thanks a million for that comment, I also completely missed that, had no idea how to do it! You made my day.

Was this reply helpful? Yes No