This video shows the notification given to a user when a vacation request is rejected. It also includes the design of the underlying app. Here is the transcript:
In the last segment, we took a look at how requests were reviewed. Now we'll take a look at what happens if the request is rejected. So you can see here on the task list, I've received a rejection from myself for this silly little demonstration. And when I click on that, I see a user interface that gives me the information I had requested vacation today and my manager told me that he needed a little bit more notice than that. And we've got a save for later our Got It button. So it's a little bit of a different look just to give you a sense of what's possible. So these pages can look very forms based or they can be very verbose with lots of extra text. So let's take a look at the design for that. So clicking from the request process, let's dive down into the user interface for this one and you'll see that like the other process activity user interfaces the property is the main business object related to this process and it's including the reviewer. Last time we included the submitter so that the reviewer knew who submitted it and this time for the person who asked for it we are including the reviewer. Task page is used as normal, but here we used a different property submit label as Got It. Now of course there's lots of different capabilities on here. They are all listed here in the different typeaheads and many of them have inline text and help that tell you how this works. So that overrides the submit button. And then we simply have a paragraph using an interpolation technique that we used in the previous one, as well as a second paragraph that is evaluated from the reviewer comments. So you can see that the design of this particular user activity is very simple. And next, we'll take a look at a service task activity.