Monday 18 June 2018

Preventing users from seeing the profile form after signing into Dynamics Portals

Like Dynamics 365, when you provision Dynamics Portals there's features that already exist so you can hit the ground running. One of these features which I often get asked about when working on a project with clients is "Can you change the sign experience where users don't see the profile form after they sign in?"

The current behaviour is after a user successfully signs into Dynamics Portals they are presented with the profile form. This is valid when the registration is "open" where any member of the public can create a log in account for themselves.

When creating an account with Dynamics Portals the only details asked are
  • Email
  • Username
  • Password
  • Confirm Password
Therefore it make sense for user to see the Profile form immediately after signing in to provide further details on their First Name and Last Name etc.

However in the scenario where registration for Dynamics Portals is invite only which is valid for some clients, then they shouldn't be directed to the profile form. Why? When sending an invitation to an individual to Dynamics Portals it's usually against a Contact where you already have details such as the First Name and Last Name in Dynamics 365.

To find out how to prevent users in seeing the profile form after singing into Dynamics Portals checkout my vlog.

Steps

The site setting to update in Dynamics 365 for Dynamics Portals is "Authentication/Registration/ProfileRedirectEnabled"


By default this is set to true. 

Update this to false. 

When you next sign into Dynamics Portals, the user experience is that they will be directed to the Home page. Ta da!

Summary

You can prevent users in seeing the profile form after signing into Dynamics Portals by simply updating a Site Setting. Zero code needed.

Till next time.

Toodles.

Thursday 7 June 2018

Grant application management Part 2: the external reviewer and applicant experience

In Part 1 I demonstrated how Dynamics 365 Universal Resource Scheduling can be used to book external reviewers for a submitted granted application.

In Part 2 I'm demonstrating the review life cycle of a grant application where
  • the external reviewer receives an email that they need to review a grant application
  • the external reviewer can comment on the grant application to request for information
  • the applicant can respond to the comment
  • when the external reviewer is ready to make a decision, they update the status of the grant application
  • the grant application is not deemed as approved until both the external reviewer and internal reviewer have approved the grant application
The above was what I recognized as the business process to be implemented and along the way I faced challenges but overcame them.

I used the following technologies and methods
  • Actions, workflows, custom workflow activity using fellow MVP Aiden Kaskela's Workflow Elements solution
  • Dynamics Portals - in particular the Notes feature
Reminder that I'm using configuration and not using additional development for the grant application management business solution.

For an in-depth walk through, watch my vlog.

Sending an email to the external reviewer

Continuing from Part 1, after the Bookable Resource is created another workflow is triggered which will send an email with a hyperlink to the external reviewer.

Usually a hyperlink is provided where it directs them to the view that displays the list of records. Given that the external reviewers have other responsibilities in their lives, I wanted to make the end user experience smooth where the external reviewer clicks on a hyperlink and it will automatically redirect them to the application in Dynamics Portals. This is where I came across the first challenge.

Challenge 1 - How to allow the external reviewer open the application record directly in Dynamics Portals

When you open/view a record in Dynamics Portal, you will see the web page URL and the GUID of the Dynamics 365 record.

I knew how to create the hyperlink by using the url path of the web page that loads the entity form but my problem was how to retrieve the GUID.

Enter MVP Aiden Kaskela (round of applause) #whoishe
He created Workflow Elements solution which had a number of cool custom workflow activities that can be used. I recommend you do a test drive yourself as you might find that there's a use case for one or multiple custom workflow activities.

The custom workflow activity step that I used is "Workflow - Get Metadata."


Using they hyperlink wizard in the workflow step that sends the email, I inserted the web page url that displays the entity form.

The next step I did was using the form assistant, I inserted the slug for the Get Metadata and referenced "Record ID" which grabs the GUID for the Application.


The external reviewer experience is that when they click on the hyperlink when they receive the email is that they will automatically be directed to the application record in Dynamics Portals.

If they are not signed in, the outcome will be the following


This is because there is a web role required to access the web page and since they are not signed in they see this. The message displayed can be updated using a Content Snippet to prompt the external reviewer to sign in.

If they are signed in, the outcome will be the following


Pretty nice.

Decision

I did find a way for the external reviewer to see the Sign In web page if they weren't signed in by inserting the Sign In URL path in the hyperlink. This wasn't a great solution as if the external reviewer was signed in they'd be directed to the Sign In page.

I weighed the pros and cons, decided the option to direct them to the review application web page was better.

Unless someone can suggest something better? (Hey Colin if you're reading this feel free to let me know).

Allowing the external reviewer and applicant to communicate to each other

The external reviewer can comment on the grant application to request for information. In turn the applicant can respond back to the external reviewer.

I wanted to reduce the two parties emailing each other. Why? For these reasons
  • Prevent the email addresses to be shared in case either become disgruntled. They really should get in touch with Sir Grants A Lot to raise an issue.
  • Emails get lost and if someone else from Sir Grants A Lot needs to step in, it's easily visible in the Grant Application under Notes.
  • Driving more foot traffic to the portal is another way of getting more interaction of your content with your users. As humans we have the tendency to look at other information available so if Sir Grants A Lot had other meaningful content for their external reviewers or applicants, they'd find it on the portal. Less likely to get a hit rate if emails were sent.
My weapon of choice was enabling the Notes feature for Dynamics Portals. I could have used Timeline Control (upcoming vlog on this) but decided to stick with Notes as no other type of activity is going to be exchanged.

Once I enabled it and tested it out, it worked fine.

I then had to configure a workflow that will notify the external reviewer or the applicant when a new note was created so that either party can respond. Sounds simple right?

OK so when a Note is created from the portal, the only way to know the author of the note is to take a look at the Title field. In the Title field the Contact fullname and GUID of the Contact is stored in the Title.


I thought I could do this type of conditional step in a workflow:


However I couldn't as when you go to the regarding entity which is Application in my case, it will only display string/single line of text fields as this is the field type of the Title field in the Note entity. External reviewer and applicant is lookup fields therefore it's not displayed.

I came across this obstacle. However ain't no mountain high enough for this sista! #word #youfeelme

Challenge 2 - How to do a conditional workflow that will check who was the author of the Note

Now I don't want to take full credit for this as I happened to be talking about it with my technical consultant and suggested to use Actions. Sweet, gave it a go and it worked like a charm.

I used an output argument for a string field that will assign the value of the regarding application external reviewer or applicant field.



I then used this action in my conditional workflow that will now call the action to check if the Title contains the assigned value of external reviewer or applicant.


Yes. Almost there.

Challenge 3 - How to allow the external reviewer or applicant open the application record directly in Dynamics Portals

Next obstacle to overcome was providing the same experience from step one where the hyperlink provided directly takes the external reviewer and applicant to the application. A nice consistent experience. Or you could call it OCD.

I wasn't able to use Aiden's custom workflow activity step (cue the violins) as it will retrieve the GUID of the Note. 

What I did do was create a custom field in the application that would store the GUID on create of an application. I have another workflow that will perform this and it does use Aiden's "Workflow - Get Metadata" custom workflow activity step.


I then used this custom field in my hyperlink to insert the GUID. This is the end result:

Decision time

When the external reviewer is ready to make a decision they update the status of the grant application by clicking on two "buttons."

Behind the scenes these are two on demand workflows configured as actions against the Dynamics Portals Entity Form.

I have one on demand workflow that will update the external reviewer status to "Approved" and another that will update the external reviewer status to "Declined."

When an external reviewer is ready to approve or decline, they simply click on the button and the external reviewer status reason will be updated immediately.

Grand finale - two approvals equals Approved

The grant application is not deemed as approved until both the external reviewer and internal reviewer have approved the grant application.

This was fairly simple to achieve by having another workflow update the Status Reason if both the internal reviewer and external reviewer status reason equals Approved.

Summary

You can create a business solution for grants application management using Dynamics Portals and Dynamics 365 Universal Resource Scheduling. This was the challenge I set myself and it turned out great. Even though I had faced obstacles along the way, I overcame them by using different methods.

Some people don't like Dynamics Portals but I honestly really like it. Once you learn Dynamics Portals it's not difficult to create something cool. And then when you team up with another complimenting service like Universal Resource Scheduling, it makes the business solution even more cooler. I'm still learning Universal Resource Scheduling and am so keen to see what else can be done with it for custom entities.

What I would like to experiment further is create a model driven app for the internal reviewer experience.

Till next time.

Toodles.