Setting up the console

For a new console installation, the console administrator needs to create the experience for users when they log into the console. This task involves working through the console content from the basic building blocks to the high level organization and presentation of these resources so that users can quickly find what their way around and perform their tasks efficiently.

To get started setting up the console, you should already be familiar with the concepts and characteristics of the layout. You should take time navigating through the console to become familiar with the widgets, dashboards, views, roles, and preference profiles that are provided. As you work with the console, you will create some of these resources to suit your organization's needs.

Understanding the structure of the console

Access to each level in the console organization is assigned based on the users' roles. Keep each role in mind when planning how to structure the console content.

Content in the console is composed of widgets. Access to each dashboard, and to each widget on each dashboard, is assigned to users based on their defined role.

Each dashboard is accessed from the navigation bar, either from the console root or they can be grouped into folders. The hierarchical structure of the navigation affects how quickly users can find a dashboard and work with the widgets on that dashboard.

Folders and dashboards can be assembled into views that the user can select from the View icon in the navigation bar. Each view can include dashboards that are initially launched when the view is selected.

Finally, you can define a set of preferences, called a preference profile, that determines what views are available to each role, and whether the navigation pane should be displayed.

Process for planning and setting up the console

Setting up the console is an iterative process. While you should initially start with organizing dashboards, roles, and widgets and work your way up to setting up views and preference profiles, over time you will need to come back to any of these steps to make changes.

Procedure

  1. Define your console users and what tasks they perform. Console users are assigned to roles, which are used to determine what tasks they can perform. As you assess the users' tasks, think about how these roles will be defined. Consider how the community of users will be assigned to different roles and whether there are any existing roles that you can use, or if you need to create new roles.

    Roles can be created without assigning access to any resources. This step can be performed later.

  2. Review the content. Users' tasks are performed using widgets on dashboards. You need to understand what widgets are available and how they will be used to perform these tasks. For each widget, determine which roles should have access and which roles should be restricted.
  3. Create a navigation structure of dashboards and folders. Determine which dashboards are currently used to access the widgets. Are these dashboards sufficient for the roles that you have defined, or do you need to create new dashboards? For existing dashboards, do you need to add or remove any widgets or change the way they are arranged on the dashboard? Consider that multiple roles can access a dashboard with different access to the widgets on that dashboard.

    Review the folders in the navigation and the dashboards that are contained in these folders. Do these folders help the users find their content? Do you need to edit existing folders or create new folders? Should you move any dashboards between folders? What folders or dashboards should be hidden for each role?

  4. Organize the content and navigation into views. Determine which navigation folders and dashboards have a related purpose for each role. You can define one or more views for each role, and even make a single view appear differently between roles based on access control. Each view can also include one or more dashboards that are launched when the view is selected. Each of these options is provided to help remove other content and dashboards that can distract users.
  5. Define the presentation for each role Determine which views should be available to users in a role. You can assign one preference profile per role.
  6. Test the console for each role. Create a test user for each role. Log into the console as each user and verify the use cases.
    • The view selection list shows only the views to which the role has access and as defined by the preference profile.
    • Each view shows only the navigation nodes and startup dashboards allowed for that role.
    • Each folder shows only the dashboards allowed for that role.
    • Each dashboard launched in the navigation bar shows only the widgets allowed for that role.
    • If the role has Editor access to a dashboard, the Edit Page option is available in the Page Actions selection list. This option is not shown if the user's role does not have Editor access.
    • Each dashboard shows only the widgets allowed for that role.
    • The widget title bar provides an Edit options icon icon that provides access to two options, a Personalize option, and an Edit option. The Personalize option is available, if the user role has Privileged User access. The Edit option is available if the user role has Editor access. Otherwise, neither of these options are available.

    Go back and make corrections as indicated by the results of your testing.

  7. Move the console to production use. Assign roles to actual users and notify the user community that the console server is ready for use.