How to use this Knowledge Base
Our Nimbus knowledge base (KB) is written to always reflect the newest development state of Nimbus and related add-ons. Nimbus is Software as a Service (SaaS), meaning that all our customers should ideally see and use the same Nimbus development state at all times.
SaaS also means, that the design and functionality of Nimbus can be subject to change. As we update and patrol all Knowledge Base pages on a regular basis It may occur that screenshots or UI elements appear different in your personal view of Nimbus. This can have several reasons:
- We used mockup screenshots to convey a certain point or functionality. Detail designs (color, font-size) may vary towards what you see in Nimbus, but the overall functionality should be the same.
- The deployment of new updates may be staged. As we roll out (mainly service-disruptive) larger updates it can happen that you find functionality described in the Knowledge Base that is not available to you (yet).
- Of course it can still be that information is false or not up-to-date. In either case don't hesitate to get in touch with Nimbus support via the following channels: Luware Support
Website https://luware.com/support/ Helpdesk https://helpdesk.luware.cloud Service Status https://status.luware.cloud/
Structure and Audience
Our Nimbus is written for both Administrators as well as End-Users in mind. Our secondary goal was a "To to Bottom" approach, covering everything from early setup and understanding how Nimbus works down to the eventual usage, everyday application and reporting data outputs.
To address these requirements, we structured the chapters as follows:
| KB Main Page Structure | Details | Recommended Audience |
|---|---|---|
| Introduction to Nimbus | Explains many concepts that help to understand Nimbus. We also use this section to provide newest Release Notes or other information that takes a "General" direction – such as Feature overviews or upcoming maintenance details. | Everyone - Newcomers, existing customers and curious minds alike. Come here to find an entry point into Nimbus. |
| Nimbus Installation | The section that explains how to bring Nimbus into your world. Good knowledge about your Azure / User Management is essential to quickly progress through this part. | Tenant Administrators or professionals in charge of managing the IT infrastructure. Our onboarding team will assist you with the process. |
| Service Provisioning | Focuses on getting the first services up-and-running on your MS Teams client. Tasks still require your Tenant Administrator, but the service owners can be involved at this point already. | Tenant Administrators, Service Owners and Supervisors with technical expertise. Our onboarding team will assist you with detail questions. |
| Administration | Focuses on getting all shared resources, workflows, users configured for your services. The KB structure follows the Administration UI of Nimbus. | Tenant Administrators, Service Administrators.  Here it is important to involve your team leads to build a Service structure, assign roles and determine tasks to avoid conflict situations when managing the structures behind Nimbus. |
| Usage of Nimbus | The "Hands-On" chapter. Explains the Front (Portal) UI in full detail. Covers individual service configuration and call handling aspects. Reporting capabilities of Nimbus are also explained in full detail. | All End Users: Agents, Supervisors, Service Team Owners, BI Specialists. A bit of training may be involved at this point, but most aspects of daily use should be self-explanatory or covered in the KB. |
| FAQ and Troubleshooting | Detail solutions and known issues. Here we cover frequent questions, either tackled with instructions in our List of Use Cases that guide through several parts of the Nimbus UI. Any issue that we can't immediately resolve is also covered in this section, either with a rationale or workaround if available. | All Users. Depending on the question or issue the contents may require certain know-how. Also refer to our Nimbus Glossary for an explanation of technical terms. |
Also refer to Role Access Concept to learn more on how to split tasks among your userbase.
Safety and warning messages
Type: Tip / Hint / Checklist
Tips / Checklists / Before you start
Hints like these contain recommended or pre-required topics to consider, such as:
- Installation conditions
- Checklists / actions
- Prerequisites
- Preemptive steps
→ and their results
The goal of tips is to save you time or recommend doing things in an efficient order.
This is the mini-variant that you might find within text or instructional steps.
Type: Info / Navigation
Information
Here we emphasize directly related topics and concepts for you to keep in mind. Among these you'll find;
- Related chapters
- Sources on the web
- Listings and overviews
- Links to diagrams, appendices and concepts
- The next logical topics for your reading flow
This is the mini-variant that you might find within text or instructional steps, usually in combination with a link to further topics.
Type: Note / Attention
Important Notes
This is an important note that warns you of:
- Necessary precautions to avoid issues
- Important user or system requirements
- Potential sources for error via either a misconfiguration or during usage
- Tricky fallacies that might not be obvious at first glance
- Known issues and their workarounds
Negligence of notes usually leads to erratic system behavior, minor loss of time or other (recoverable) issues. We therefore highly recommend you read these warnings carefully.
This is the mini-variant that you might find within text or instructional steps.
Type: Warning / Critical
Warning of Critical Conditions
We use this one sparingly because it's very important. A critical message warns you of problems that may result in severe infrastructure impediments.
- Multiple sources ...
- ... or follow-up problems could be mentioned here
→ Consequences like permanent loss of data or widespread infrastructure malfunctions are highlighted.
- Instructions might be included in these warnings
- ... or shortly thereafter in numbered steps.
→ The expected result state follows for those steps (if there is a system reaction or result to be verified).
Negligence of warnings usually leads to a faulty system behavior, considerable loss of time, up to a point where your system might be unrecoverable without severe loss of data. We highly recommend not to skip these warnings at all.
This is the mini-variant that you (rarely) find within paragraphs or instructional steps.