Originally, I was planning to write three of these but I will write one more after this on Web Forms. This post will focus on setting up Entity Lists and Entity Forms which, in effect, allow you to publish CRM Forms and Views directly to the Portal.
Publishing CRM Views
To publish both Forms and Views to an Adxstudio Portal, you need three things:
- The CRM Form or View you want to display (this can be a system Form/View or a custom one)
- An Entity Form/Entity List record in CRM
- A Web Page in the Adxstudio Portal
In this example we will set up a list of Account records and have a form available to use so we can edit the records.
Creating the CRM View
In this case I will use the standard Active Accounts view so there is little setup to be done. However, there is nothing stopping you creating a custom view and using this instead.
Creating the Entity List Record
This is, arguably, the trickiest part of the process. There are a couple of reasons for this. Firstly, the Adxstudio configuration forms in CRM have a lot of fields which, for a basic set up, are not needed. However, it is not always clear to a novice which these are and it can be a bit overwhelming. Secondly, there are helper objects throughout the form which are slow to load and sometimes time out (more of a problem if you set up CRM outside of the US data centers). This means the form can be locked for, say, 10 seconds or not quite load correctly, confusing a new Adxstudio administrator. If the form does not load correctly, this can be remedied quite easily with a re-opening.
For both the Entity List and Entity Form, you can find these in CRM under the Portal area.
The key fields on the Entity List record for our example are:
- Name: The CRM default field for the record and needs a meaningful name for the record. In our case, ‘Client List’
- Entity Name: The entity the view belongs to e.g. account. This is added via one of the Adxstudio helper objects which handily lists all the entities in CRM as a drop-down list.
- Views: The views to show. In this case we add only one view: Active Accounts
- Page Size: How big the list is in rows
- Web Page for Details View: This is the Web Page to open if we want to see the form related to a record. In our case we have not set up the Form’s Web Page yet so this is a field we need to fill in once that is done (it is completed in the screenshot below but you will not be able to populate it at this stage). It also requests an ‘ID Query String Parameter Name’. This is a value passed to the Form’s Web Page to determine the record to render. Generally this will be ‘id’ i.e. the GUID of the record
- Web Page for Create: If you want Portal users to create records from the list, you will need to specify another Web Page here. In our case, this will also be the Web Page for the Form we are setting up later.
That is it. The rest of the fields on the form can be safely ignored for our example.
Setting Up the Web Page in Adxstudio
For displaying the View, the last step is creating our Web Page. To do this we need to open up the Portal and log in as an Administrator, like we did in Part Two.
The Web Page you create has to be a child of an existing web page so, in this case, I will go to the home page of the Portal and set it up there. To do this, go to the floating box on the right and select New-Child Page.
The configuration box that appears is surprisingly simple.
The fields we need to populate are:
- Name: A name for the Web Page which I usually make the same as the View name in CRM
- Title: The name which appears at the top of the Web Page in the Portal
- Parent Page: Autopopulated and, in our case, the Home page
- Partial URL: Autopopulated and specifies the bit of the URL after the slash to uniquely identify the page
- Page Template: There are a bunch of these pre-defined for the Portal with sensible names. I usually use the Full Page template
- Publishing State: Autopopulated with Published which, for our purposes, is fine
- Entity List: The Entity List record in CRM used to work out what to show. In our case it is the Entity List record we just created, the Client List record.
Once this is done we simply hit the Save button and we are done. The Portal will automatically take us to our page but for regular access, we will want to add the Web Page to our navigation (the process for which we covered in Part Two).
Once added to our navigation, we can click on the navigation link at any time and show the list of records rendered live from CRM.
In the above screenshot you will notice the values in the first column are blue, indicating a web link. At this stage your fields will be black. This link is defined by the Web Page for Details View which we can define once we set up our editing Web Page i.e. the Entity Form.
Creating the CRM Form
In this case I will use a custom Account Form I have called “Client Summary”. This will act as our edit form in the Portal.
Setting up the Form is the usual CRM process. It should be noted that some Form objects will not necessarily render in the Portal correctly e.g. the Social Pane but this is something you can play with for yourself. Here is my Form in CRM (also note that I have renamed the Account entity to Client but this is not necessary and was just because this environment was part of a client demo).
This is pretty similar to the standard Account Form and I purposely left the Social Pane on there, with Activity entries so you can see what happens in the Portal.
Setting Up The Entity Form Record
This is also set up in the Portals area of CRM and the Entity Form form also has a lot of fields which, for a basic set up, can be ignored. Let us review the key fields to populate to get a Form up and running.
- Name: The usual CRM default field which, in this case, is a meaningful name to describe the form e.g. ‘Client Details’
- Entity Name: The Entity which the Form belongs to i.e. account. This value is added to the form through one of the Adxstudio helper lookups on the Entity Form record
- Form Name: This is the Form you wish to display in Adxstudio. Again, this is added through a helper lookup which uses the Entity Name to filter to only the forms for that entity
- Mode: This is how you want the Form to behave in the Portal. The options are Insert (if you want the Form to be used to create a new record), Edit (if you want the Form to be used to edit an existing record), and ReadOnly (to display the record without the ability to edit the details). In this case, as I am using the Form to edit a record from a list, I will select Edit. If this was a standalone form e.g. a Contact Us form for Lead creation, the Insert would be a better option.
- Record Source Type: This is used to work out what record to use when opening up the Account Form. The options are Query String (which specifies a parameter for the URL of the form). The default value is ‘id’ i.e. the record GUID (which is the option for our purposes and links to the value specified in the Entity View setup for the Web Page for Details View field), Current Portal User (which shows the User record for the person logged in to the Portal and is useless for our purposes), and Record Associated to the Current Portal User (for this one you also specify a lookup relationship to link to the right record e.g. we could use this option and specify the primary contact relationship so that the Account for which the Portal user is the primary contact is displayed.
That is it. The rest of the Entity Form can be safely ignored for our demonstration purposes. So now we have a CRM Form, an Entity Form record and the final step is creating a Web Page to show it on.
Creating the Web Page
This is very similar to the process for setting up the Web Page for the Entity List. In this case we will create it as a child from the Client List.
The key difference is that rather than specify the Entity View, we specify the Entity Form.
If you specified both an Entity Form and Entity List here, both would display on the page but this is not required in our case.
Once this is done, you are finished. Congratulations, you have set up a CRM View and Form to display in an Adxstudio Portal.
The end result will be a Portal with a link to client details which shows the accounts in CRM defined by the View.
You will also notice a Create button on the right which appears when the Web Page for Create field is specified in the Entity List record in CRM.
Clicking on the blue name of the record opens up that record in an edit form.
Although it fell outside of my screenshot, there is a Submit button at the bottom of the form so you can submit your changes which immediately get written to CRM.
As you can see, the Social Pane does not render correctly, only showing notes on the record, so be careful of this when setting up forms for use in the Portal.
The power Adxstudio brings to Dynamics CRM for rendering forms and views in a portal for external consumption is amazing. Without Adxstudio, setting up this scenario would take significant web development and testing. Adxstudio takes all the pain out and means the portal is defined through configuration and not code. A process that may take a week through traditional development can now be achieved in an hour or so.
If you have not considered Adxstudio Portals as a portal engine for Dynamics CRM, it is definitely worth reviewing and, hopefully, with this set of blog posts, the barriers to entry for their set up is a little less high.