Since MS Dynamics CRM is created as a single-page application, meaning that it does not reload at any point, URL does not change when you go from one view to another or when opening forms of different records. Therefore, it would seem that entity forms and views cannot be addressed through URL. However, since that property is quite handy, MS Dynamics CRM enabled addressing different parts through URL. There are numerous situations in which getting URL of specific view or form of specific entity record is needed: i.e. you want to send it to your colleague, you want to bookmark it etc. That is why, we are going to dedicate this blog post to creating URL which would address specific entity form or view.
Standard URL of the MS Dynamics CRM Online would be:
https://orgname.crm.dynamics.com/main.aspx
Adding “?” mark and different parameters at the end of this URL can get you to different parts of MS Dynamics CRM.
These parameters can be added:
- etn: specifying entity name of entity that is addressing (i.e. etn=account).
- extraqs: if the form is being addressed, instead of id, certain criteria may be passed through URL and the form of the first entity record that satisfies the criteria will be opened. This parameter is used for setting that criteria in following format: extrags=criteria, whereas the criteria must be encoded. Criteria is written as: field1=value1&field2=value2&field3=value3… Therefore, criteria consists of one or more conditions, each of them consisting of single entity’s field on the left side, “=” mark and certain value on the right side. If more than one record satisfies the criteria, first of them will be addressed. URL encoding means that all characters should be in valid ASCII format. For instance, marks “=” and “&” should be encoded as “%3D” and “%26” respectively.
- pagetype: whether view of form is being addressed. For the form, write pagetype=entityrecord and for the view, write pagetype=entitylist.
- id: if the form is being addressed, this parameter is used for specifying concrete record that is being addressed. Id is in the form of GUID and it is written in { } brackets (i.e. id={80221813-703B-4BDD-A910-35FG9E710417} ). Later, brackets are encoded in %7B and %7D respectively. If this parameter is omitted, form of a new record will be addressed.
- viewid: if the view is being addressed, this parameter is used for specifying concrete view that is being addressed. Same as Id of the form, it is in form of GUID and it is written in { } brackets (i.e. viewid={6FE93A1A-C24F-448A-BFA8-D642AA8F37D2} ). Later, brackets are encoded in %7B and %7D respectively. There are numerous ways how to obtain this id: it can be fetched from View entity or can be read from URL of the view editor (Open the view and click on “View” button on the command bar). The viewid works fine both with system views (saved queries) and with personal views (user queries).
- viewtype: if the view is being addressed, this parameter specifies whether the view is system view (savedquery) or personal view (userquery). If the view is system view, then write: viewtype=1039 and if the view is personal view, write: viewtype=4230.
- navbar: this parameter controls whether the navigation bar will be visible or not. It has three possible values: “on”, “off” and “entity”. Writing navbar=on would mean that the navigation bar will be visible. Since this is default value, if this is desired behavior, the navbar parameter can be omitted. Writing navbar=off would result in hiding navigation bar from the top of the page. Finally, nabar=entity would result in showing navigation bar, but instead of common set of areas and subareas with links to CRM entities, the navigation bar would only contain the list of links to related entities of the entity whose view/form is addressed.
- cmdbar: this parameter controls whether the command bar will be visible or not. It can have two values: true and false. The default value is “true”, so only if you want to hide command bar, you should write cmdbar=false. Otherwise, this parameter should be omitted.
Thing to have in mind is that addressing views and forms in this way cannot break security restrictions. The one who is not a member of the organization cannot access views nor forms. Also, the user who does not have privileges over certain entity record will not be able to visit URL addressing that entity record.
Let’s look at several common examples of using URL for addressing forms and views:
- Addressing Contact’s view “Active Contacts” (system view)
https://organizationURL/main.aspx?etn=contact&viewid={00000000-0000-0000-00AA-000010001004}&pagetype=entitylist&viewtype=1039- Addressing Contact’s view “Ajdin’s Contacts” (personal view)
https://organizationURL/main.aspx?etn=contact&viewid={8A4CF3A8-2F1C-E611-80DC-5065F38BF1B1}&pagetype=entitylist&viewtype=4230- Addressing form of a new Opportunity
https://organizationURL/main.aspx?etn=opportunity&pagetype=entityrecord
- Addressing form of Competitor with id = { d8e5d429-0cf3-e311-8701-6c3be5a8174c }
https://organizationURL/main.aspx?etn=competitor&pagetype=entityrecord&id={d8e5d429-0cf3-e311-8701-6c3be5a8174c}- Addressing form of the Account with the name “Kahrovic Company”
https://organizationURL/main.aspx?etn=account&extraqs=name%3DKahrovic%20Company&pagetype=entityrecord
No comments:
Post a Comment