Navigation - Menu and Landing pages ----------------------------------- VOSS Automate provides several tools for customizing the Portal experience to your requirements. The advanced Admin Portal utilizes two key ways to provide users with the means to navigate around the system to key features: * Configurable navigation menus (on the left of the screen) * Configurable Home page - this is the page you see when logging on or when clicking the Home button Configuration options to enhance navigation: * Naming of menus and the landing page - it is recommended that you use terminology that reflect the tasks users need to perform, such as business process naming for admins, or more technical terms for advanced users. * Linking from menus - typically, to the form/view, list, or other system model users require access to for various tasks. * Display Policy - for views, or when users select an entity from a list view, which determines the form layout users see. * Configuration template - this is applied when a view is accessed from the menu item, or the add action is selected from a list view. This can drive the entity during the add process. This can also be for visible fields to act as a default (or a fixed value if the field is read-only) or drive fields hidden by the display policy to provide fixed values. * Filtering - both mechanisms provide advanced filtering mechanisms to drive different experiences. There are two key types of filters: * Fixed Filter - this is defined on the menu and cannot be seen/changed/removed by the user. The user is unaware a filter is applied and it is the baseline list view they see. They can apply further filtering as needed. * Configurable Filters - these are filters that can be fully or partially defined in the menu for items pointing to a list. This option gives an interim step between clicking on the menu/landing page option and getting to a list view. It will pop-up the filter options for the user to enter any filter criteria they require and it will be pre-populated with any criteria defined in the menu. Once submitted the list view is rendered using the provided filter criteria. The filter can be seen, changed, or removed as needed by the user. See the Core Feature Guide for more information on each of these elements and for configuration steps. Below we'll outline some suggested strategies and considerations to utilize to create the most efficient means for you different users types to get to the key capabilities they need. The general strategy is that you want to make the most common tasks as quick and easy to get to for the different user types of the system. We suggest you use these capabilities to create the menu and landing page experiences you need to suit the different user roles that you set up in the system. In addition, the capabilities and experience needed for the user roles should be reviewed regularly with the users to look for additional opportunities to streamline and improve their experience to drive even greater efficiency or evolve to their changing needs. Here are some key goals that should be provided through these capabilities. Quick Access to tasks/searches: ............................... The landing page should be populated with the most common tasks and/or searches that the user will be performing. This gives one-click access to those tasks/search from a single place and they can always quickly return via the home link at the top of the page. This makes the experience far easier and more intuitive for the user and saves them from needing to learn a specific menu structure or where items are to access. It is front and center and in terms they can easily understand. Some examples of this: * The top MACDs they do in the system should be on their landing page and easily accessible - with appropriate display policies and configuration templates. See the Simplified and Streamlined feature experience section below for more guidance on this * Create landing page entries that are saved searches with defined filter criteria for one-click access. This can save time and effort as well as make the searches available to a wider audience. As an example of this - List un-registered phones which would be a link to phones with the criteria set to status starts with Un-Registered. This would the user one click access to unregistered phones in the system. * Create landing page entries that have some criteria defined to help guide the user through a search they frequently do but has varying criteria. This walks them through the search process rather than going to a list view, to them pull up a filter and define all the criteria each time. For example, find a phone by user - this can be done with a landing page entry for phone, filter criteria set to ownerid, and then the user will be prompted to provide the required username and submit. This would give them one click access to finding a phone when they have a userid to work with. * If there are more tasks than landing page space, then the menu can provide that access to the more edge case and deeper functions that the user might need from time to time. Simplified and Streamlined feature experience ............................................. Rather than create a single link for a feature that handles a lot of different scenarios, it can be better to include multiple menu/landing page entries to the same feature with different display policy, configuration template, and filter options tailored to a specific use case. This can be a very simple way to create an experience of the feature that better suits a specific use case resulting in a more intuitive experience and improve automation. This streamlined experience can also reduce errors or reliance on users to follow a procedure and enter the right information for different scenarios through the same feature. This can also allow what would typically be more advanced capabilities to be exposed to lower level admins in a way that aligns to the business function. Some examples: * Create a link for adding SIP trunks as part of a specific 3rd party application integration that is regularly added. This can link to the SIP Trunk device model, utilize a display policy that hides virtually all the settings except those require entry - such as IP address and port of the remote system. The configuration template could define all the other technical settings according to that scenario (e.g CSS, call presentation information, digit manipulation, etc). * Creating lines for different scenarios - there are a lot of different lines settings and optimizing the experience for different scenarios can greatly reduce effort and errors in setup. The display policies can be used to cut the visible fields down to those strictly needed for entry, while the configuration template can drive many of the detailed settings for the different scenarios. The result is you could add menu items for lines type A, line type B, etc. This makes it very simple to create these different types that align to the business task they understand without potential errors of the user deciding the right settings for the situation. This can even be combined with the filtering capability in the menu/landing page to separate these line types in the listing for full separation. * UCM feature management - for some UCM capabilities there is not a specific feature built in VOSS Automate for managing it however they can still be accessed via the device models directly. The default device model layout is driven by the API definition from Cisco and can often include field names and order that do not align to the admin experience. This can easily be improved with a display policy to create the order you want and field labels that suit your needs. These can also be combined with Configuration Templates again to set defaults or drive hidden values to simplify the input and reduce errors in setup.