MS CRM - heavy customization of edit.aspx form

Question

I have a use case which I think can only be modeled by heavy customization of the CRUD form; hoping there is a better way, and if not, for any kind of insight :)

I need to model a use case where the standard create Referral (custom entity) form is a sequence of stages (eg. tabs with logical previous/next buttons). I need to hold the user's hand in going through these steps, creating child entities, and lots of hidden/related attributes as he moves on in the process. When later retrieving this data in views I will probably end up using FetchXML with various loosely connected entities.

The real issue is that this should popup as the default form (for specific roles), when clicking the hyperlink to the entity anywhere in the CRM. So far I modified the /UserDefined/edit.aspx to check for my specific entity type and user role and redirect him to a new page (which for now is a slightly modified copy of edit.aspx).

I could just write the whole new page from scratch and use the SDK to query/update fields, but I was wondering if I could still load the default frm:CrudForm as crmForm and use it's attributes/methods. Any thoughts?

1. I don't like the redirect OnLoad() method, but the alternative to grep/sed all places where the default edit.aspx url could pop up (in the CRM aspxs) sounds even worse. Is there a third option?

2. Should I write the aspx website from scratch, or should I try to tie this in with the default CrudForm? If the latter, can you offer some advice on how to go about this; such customizations seem to be far from standard and are not well-written about ;)

3. Is there a better way to approach this use case? Maybe I missed some basic insight in how I could use the standard CRM features to fix this. (at first glance, the default Workflows are not really an option-> I originally worked it out like this, creating tasks and using public queues for every step of the process, but from a user's perspective this is a real mess -> hard to get a grip where exactly in the referral process we are)

Answer 1

To stay completely supported, could you just create a tab for your custom entity that has an iframe on it, load up your custom ASPX page from there, and just hide/remove the rest of the tabs through javascript?

Monkeying around with out of the box CRM pages is definitely unsupported, so you probably won't find many resources for that. If MSFT sniffs that you've made unsupported customizations, they'll likely refuse support requests should you/your client even need them.

Answer 2

For the record I agree with Matt.

I don't like the redirect OnLoad() method, but the alternative to grep/sed all places where the default edit.aspx url could pop up (in the CRM aspxs) sounds even worse. Is there a third option?

Couldn't you just have javascript onload for just your entity which does a redirect. Your object type code is subject to change across installs so it really keeps you from having to modify the edit.aspx at all.

Should I write the aspx website from scratch, or should I try to tie this in with the default CrudForm? If the latter, can you offer some advice on how to go about this; such customizations seem to be far from standard and are not well-written about ;)

I would write your website from scratch. Too much to worry about in the context of the CRM form for a complicated business process.

Is there a better way to approach this use case? Maybe I missed some basic insight in how I could use the standard CRM features to fix this. (at first glance, the default Workflows are not really an option-> I originally worked it out like this, creating tasks and using public queues for every step of the process, but from a user's perspective this is a real mess -> hard to get a grip where exactly in the referral process we are)

Like Matt and you say, create your own set of web pages. You're not going to be subject to upgrade problems and it'll likely be easier to do than trying to hack your polish into CRM's forms. Creating your own ASPX will be standard and supported while modifying theirs won't yield you much help in any troubles you come across.

Hope I didn't mis-understand anything.

Answer 3

Going off of Matt's idea...

I'm thinking I would use the standard form as much as possible to save some time.

1. Customize the form (the normal UI way) to include a section for each step in the creation process.
   
   • Put whichever fields you need into section.
   • Make sure you display the section name so that it will be easier to hide the section later.
2. For the steps that ask the user to create related records, create a section that has just an iframe in it.
   • Use the iframe to point to a custom page that helps the user create the related record. Note that since the record we're guiding the user through hasn't been created yet, the related records the custom page in the iframe helps them create won't be able to reference it yet. You may want to consider redesigning when the user creates the related records.
3. Add code to the OnLoad event that checks the users role. (See Ronald Lemmen's post for help. In your case you would hide sections.) If you determine that the user needs hand-holding to create the record:
   
   • Hide all of the sections except for the one that represents the first step.
   • Add Previous and Next buttons somewhere on the form.
     • Set them up so that they control which section is visible to the user depending on which step they're on.
   • After they have completed the last step, programmatically save the form which will create the record.

Hope that works. Good luck!