Walk-up Experience Best Practices... do's / dont's

[robertsduca]

Can anyone share any best practices, do's / dont's specifically related to customizing / extending the walk-up application? Above and beyond standard BPs and specific to Walk-up.

Specifically I am referring to as things relate to branding, possible page/widget changes, creating a new portal all-together (should we or edit oob) and cloning OOB pages, etc.

I see that it's very configurable but what is considered the 'red line' before we start risking compromising upgrades, etc

This is a great 'turn-key' app but it's unrealistic that any customer would typically want to use it 'as-is' to a certain extent and really brand it to align to their 'own' vision for a 'tech lounge' , etc experience.

Any advice before we embark would be if great assistance here.

[Geoffrey2]

Hi,

I have had a good look at Walk-Up Experience. There are 4 places you would expect a customer to want to restyle the look and feel of Walk-Up Experience.

• Online Check-In (Service Portal)
• Onsite Check-In (tablet)
• Queue screen (TV)
• Exit Survey (tablet)

For this very reason, all these screens have been built on service portal. It has been built on service portal specifically so that customers can restyle/brand them, as explained on this Docs page: Configure the Walk-up Experience portal.

Ideally you would try to localise your custom styling to the relevant service portal Themes. This is a single record that contains CSS used by the whole portal. The online check-in uses the default Service Portal (/sp), and the tablet and TV screens use the dedicated Walk-up portal (/walkup). The online check-in should automatically pick up the custom styling of your Service Portal. You will just need to update the Walk-up Theme. This will have the minimum possible impact to upgrades.

If the customisations you want to make go beyond the Theme, then you will need to look at the Pages and Widgets. Each of the 4 abovementioned screens have their own Page and Widget. Best Practice would be to not change the structure of anything, and to try to only change the style. Leave the Page structure alone. All the widgets are read-only, so if you want to customise them at all, then you will need to create your own versions. At this point, each custom widget will have to be re-evaluated at every upgrade. You can still minimise this technical debt though. If you are customising a widget, try to leave the HTML, Client code, and Server code alone (the structure). Try and make your style changes to the CSS only. By leaving the HTML unchanged, when you upgrade to Madrid, you can simply copy-and-paste the updated HTML from the OOB read-only widget to your custom widget. Keep your custom CSS, and you should be ok. You might have a custom widget, but when you upgrade to Madrid you can simply copy-and-paste most of the code from the OOB widget to your custom widget. Then you won’t miss the new Schedule Appointment feature in Madrid.

If we look at extending Walk-Up Experience outside of its look and feel, then there are a few thinks to be mindful of.

If you are on London, I would highly recommend not making any changes at all to the data model for Walk-Up Experience. The data model changes dramatically in Madrid.

In London, Walk-Up Experience uses Interaction Management. Interaction Management is a framework that is used by other applications, such as Virtual Agent. You need to be extremely careful about any customisations you make to Interaction Management as it could affect Virtual Agent, and any other application that uses Interaction Management in the future. Best Practice is Don’t mess with Interaction Management. One common enhancement for Walk-up is to enable Technicians to create other tasks (not just Incident and Request) from the Walk-up Interaction. For example, if you have a custom task type called u_request, you can create a simple UI Action on the Interaction table to create and link a new u_request. You can limit this UI Action to only Walk-Up Interactions very easily. Since you are not changing any OOB functionality, and you are not affecting other processes, this is one customisation that has very low chance of being affected by upgrades. You should not alter the State model of Interactions though. This will affect all other applications that use Interaction Management. Don’t make any changes to the Connectors, Queue and transfer records. These are all changed or removed in Madrid.

In Madrid, Interaction Management has a lot of its functionality removed and replaced by Advanced Work Assignment (AWA). AWA is another framework that it used by multiple applications. It is used to automatically assign work items to agents in Agent Workspace. It is used by Virtual Agent, AWA for Incident, and CSM. Don’t mess with Advanced Work Assignment. The Walk-Up Location Queue table extends the AWA Queue table. You could safely add new fields to the Walk-Up Location Queue table, so long as you don’t add or change anything that will affect the parent AWA Queue table.

In Madrid, Walk-Up Experience uses the Appointment Booking application from Customer Service Management (CSM). Any customisation to Appointment Booking might affect existing CSM functionality.

To summarise: By all means, style the look of Walk-Up Experience to your heart’s content. That’s why it was built on service portal. Avoid creating custom widgets if you can, otherwise they will have to be re-evaluated with every future upgrade (introduces technical debt). Walk-Up shares functionality with other applications. So, be very careful about changing the data model, especially if you are on London. 

[robertsduca]

THANK YOU!!!

This is exactly what I was looking for.... We have made it very clear to our stakeholders that we will not be doing anything above and beyond mild branding (ie: change the black background for queue on the LCDs etc) and the PoC I have been working on looks just fine even with the logos added to the walk up location records. 

Thanks again.

[robertsduca]

The one thing I really need to change is the queue page colors... specifically the black background.. that simply inst going to work with the branding we want to use. I assume based on what you are suggesting I'll need to clone that widget and change the CSS contained within. Then re-add the cloned widget to the page.

[Geoffrey2 · Accepted solution]

Not necessarily. You can override the CSS in the widget using the CSS in the Theme.

1. Open the Style Sheet [sp_css] called walkUpPortal
2. Add this CSS at the bottom
   

   .v0ee8191653360300c6bfddeeff7b125a .walkup-queue-page-wrapper {
     background-image: none !important;
     background-color: cornflowerblue !important;
   }
   ​

Results: