Now that we’ve identified a general scope of what our portal will be, we can start to design the look and feel as well as that data structure that supports it and the security model that protects it. The following sections will highlight some common methods and practices that are utilized in Microsoft Dynamics 365 portal design. Jump to the following sections to learn more:
This section is similar to the one we covered in the identification stage. We are looking to model the expected flow of user involvement with our portal in the constraints of our business rules. We can map every expected transaction and interaction point so that we have clearly defined requirements during the implementation stage. In addition to mapping flow, we’ll also mock up visual representations of what we want our website to look like.
Flow diagrams are a great tool for mapping user interaction and expected use. Once they’ve been created, they can be used to review with stakeholders and key users to ensure that the process makes sense. The visual representation often makes this task easier. Below, you can see an example of a flow diagram:
Here you can see that the flow diagram lists each state a user will experience as well as the actions that moved them between those states.
Mock-ups provide a way to better visualize the content and flow of a portal without actually having to develop all the functionality of it. Mock-ups can range from snippets of images that have been captured and manipulated to skeleton code that utilizes basic framework components and some styling. Here are some general guidelines to consider as you design your mockups:
- When creating mock-ups for a custom screen, it may be important to identify an existing look, feel and branding of your organization. Determine if your portal should follow any existing styles.
- Be aware of the devices your users will access the portal with and make sure that you accommodate and plan for different screen resolutions. You may want to create mockups for devices like computers, tablets, and smartphones.
- Consider things like error and information messages in your design. Where will you want those to be displayed if necessary?
Below, you can see two examples of mockups–one for a user login and another for a time entry system:
Now that we have the look, feel and visual design elements nailed down, we need to architect a clear picture of our data structure that will support it. Utilizing the information we captured in the identification step, we can determine how our users will connect to the data, how the data is related to CRM and how the data in CRM and other data sources will be exposed in our portal.
Utilizing a tool like Visio, we can visualize a representation of our data as well as the users that will be accessing it. This can help us identify some of the architecture of the portal as well as specific roles and groups that we might utilize in our security section coming up. An example of one of those diagrams is listed below:
Entity Relationship Diagrams
We’ll diagram the entities that make up our CRM system and show how they relate to each other:
For each page inside the portal identify what field in what entity maps to a field in the portal and create a data mapping document for each page that helps the developers when developing the portal. Below screenshot shows an example of a data mapping document.