To solve this problem we eventually settled on a Request Entity Pattern where we gave users an AccountRequest entity with a small number of attributes that fires a server-side plug-in to create the account. Then some JavaScript in the request entity opens the newly created account and closes the request.

This pattern has proven to be tremendously useful in a number of situations so I thought I’d take a few minutes to walk through it. Primarily it provides an easy way to deal with onetime setup logic or constraints without making the target entity overly complicated. You in effect have a custom form just for the create and it also provides a number of extra injection points for plugins, JavaScript, and duplicate detection outside of the main entity. Finally it gives a built-in audit trail of each create request for key entities.

Example of an Request Entity Pattern for Account:

1. Create a new custom entity Account Request, add attributes for the required fields on account and any others needed for account setup. Make sure that required fields on Account are also marked required on the Request entity. Add an N-to-1 relationship between AccountRequest and Account named LinkedAccount.  (You want a lookup field on the account form names LinkedAccount with the id of the Account in it.)
2.  Remove the create security permission for the account entity from the users, add security permissions for create and update permissions to the new AccountRequest entity.
3.  Add an ISV Button to the Account View called ‘New’ that opens a new AccountRequest. (The original new button will be hidden by security.)
4.  Add java script on the AccountRequest to
   1. set the LinkedAccount attribute forcesubmit = true.
   2. check if the value in LinkedAccount, if it is not null open the linked account in a new window and close the request form. 
5. Create a plugin for AccountRequest
   1. Register Pre-Stage of the parent pipeline for Create and Update, and use the false option on the CreateCrmService to run in the system context, (the user does not have privileges to create an account.)
   2. If the business conditions are met then create the new account, update the account lookup attribute in the target property bag with the ID of the new account, and set the owner of the account to the user, (it will default to SYSTEM.) The forcesubmit in step 4 above ensures the account lookup attribute will be in the property bag.
6. Add custom business logic and duplicate detection as required to the AccountRequest Entity.

 Chris Condron

 The duplicate rules always fire on both create and update, and all of the conditions are OR based so there is no way to filter them out by status or other flags to indicate that this record has been reviewed & should no longer be checked. This gets really annoying when you are updating something completely unrelated and have to click though a duplicate warning again and again.

So to the fix, it is based on two elements 1) CRM allows you to duplicate check against different types of entities. and 2) We are also using a “helper” entity in the creation of our accounts called AccountRequest. (This helper is an entity with 4 or 5 attributes that collects the key information to create an account and then uses a server-side plugin to create the account entity. When the form updates a piece of JavaScript opens the new Account for the user, giving them in effect a wizard to create new accounts. I can post details if people are interested.)

 So what we do is run duplicate detection job between the AccountRequest entity and the Account entity. This will alert the user to potential duplicate new accounts and but will not run when the account is updated.

Problem solved.

We can even extend it with the soundex solution here

It stared with this:

I am a Sr Architect currently leading the QA Architecture domain for a regional insurance company. I have been writing code for about 25 years. I’ve been writing code professionally for about 15. I have been designing and creating custom enterprise automation solutions and frameworks for fortune 500 companies for about 10 years.

I also have founded or been a founding member of several small technology and consulting companies. These range from, teaching Chess to troubled youth; Restaurants (never achieved funding); Web Hosting; Custom Telecom Testing and Certification Solutions; and Online Music Sales.

And here is the post

As enterprise QA solutions (good ones at least) are tightly coupled to the SDLC I have also become involved with development process, design for test and standards.  My current beliefs on process and documentation is that there is an inverse relationship between, team connectivity and communication; and the need for formal documentation. i.e. for a small tight team, go agile, no docs all talk. for large dispersed team standards. process and docs are a must to succeed. My basic approach is to advocate lightweight and effective documentation. It should be easy to produce and contain thing people need to know. This also means that if you can’t hire a small team of quality developers to complete the project you need to spend some time thinking about how all of your docs work together.

Basically, treat you documentation and process as you would a software project, architect it and only create what you need.

Conceptually one can think of a software project as a writing exercise. Consider a project using a theoretical process in a large company:

Someone in the business gets and idea.

1. They write an email and see if people like the idea.
2. They write a charter document detailing the concept and what is in and out of scope for other business people to decide if they want it and get some idea of how much that would cost.
3. Then they bring in the BAs to write a business requirements version of the idea detailing all the things this project would do for the business
4. Next the Architecure staff writes a technical version of the idea talking about how this would work.
5. Meanwhile the BAs write a feature requirements document detailing the changes to the systems that would produce the required effects.
6. Now the development team writes a techinical document on how to write code to make the systems procude the changes the BAs have requested.
7. Finally some of the developers write code that the machines read to produce the desired effects.
8. During all of this QA is writing up notes on where and how all of these documents and code don’t agree, and making people go back and rethink and change what they wrote.

The code in effect is the final draft of a techincal paper. Formal process say all of the drafts are writen to standards by different groups. Agile process says focus on the final draft and make all of your changes there.

The basic problem all of this is addressing is that the entirety of the conceptual model for a software project quickly becomes to big for any one person to hold in their head. As soon as you need to share the model with a second person you have a problem. There are so many details and aspects of the project that interconnect and cross impact that you can’t even just put it in one document.

In agile you build a shared mindset and set of assumtions that you keep current through constant communication. Good for small teams, hard to share to larger less connected groups.

In formal proccess you publish standards and walk through a know proccess and series of documents. More overhead, but scales much better for large loosly connected groups.

Good process and architecture addresses the core issue of complexity in the conceptual model through a number of appraoches. I think Domain-Driven Design by Evans is a tour-de-force on the subject. Model clarity, separtion of domains, and the ubiquetous language to link the levels in the process stack are all wonderfull ways to make everything work much better.

More on this later.

- Chris

I was reading two good blogs about Linq to SQL and ASP.Net applications  here and here.

Based on the pattern set up by Rocky Moore (see first link) I came up with this code. Using generics and a little bit of reflection in a base class.

Here is the base class

In the partial classes created by Linq Designer here is how to add the base class

As the pattern is fixed, it is a good candidate for replace all in the partial class file.

and a usage example

This should be quite useful for detached applications.

-Chris