Local and shared content with Finder (classic)
Almost every item that a user creates in Finder is centralized, meaning that the item is added to a central content manager. In its turn, the content manager synchronizes all connected Engines to keep a copy of every added item. The result is that all Engines share the same user-created content, offering a unified experience to the Finder users.
There are a few exceptions and special cases that we detail below.
Classification
The following table classifies items according to their level of sharing:
| Centralized | Centralized | Local to Engine | Local to Finder |
|---|---|---|---|
Owned | Shared | ||
|
|
|
|
Owned content
Even if most of the content is replicated in all Engines, some types of replicated items belong exclusively to the user that created them. Thus, when connecting to an Engine instance with Finder, only the owner of that content is able to see it. Investigations, one-clicks and the alerts in the My alerts section fall into this category of items.
Shared Content
Many of the items that are replicated by the content manager are shared by all users. However, these items are usually associated with a configuration option in the profile of the user, so that only the users with the corresponding option ticked are able to manipulate their content. For instance, although all users can see the visible scores of an object, only those whose profile allows system configuration can manage the scores. For a list of all the profile options, see how to define user profiles.
Services, for instance, are also visible to all users, although only those with specific permission in their profile can modify the definition of a service. Similarly, while categories and keywords can be managed by users with the right permission only, their effect on objects (that is, the tags) is visible to everyone. Other types of items such as metrics, campaigns and remote actions are removed from the left-hand panel of Finder when users do not have permission to modify them.
Content local to an Engine instance
Although tags do not really qualify as user-created content, they deserve to be mentioned in this section about locality, as tags are the only items that are local to Engine and that users can modify.
Tags are neither centralized nor shareable. A tag is the result of applying a keyword of a category to an object either manually, automatically or with the help of text files. Objects (devices, destinations, etc.) live in the database of each Engine; therefore, objects are local to an Engine instance, and so are the tags applied to an object. The locality of tags has some important implications which are explained in the following example.
Suppose that you have a setup with two Engines and one Portal, and in both Engines there is a destination with the same IP address. In fact, even if it is logically the same destination, there are two destination objects: one per Engine. If you create a category and a keyword to automatically tag the destinations with that IP address as, for instance, a Mail server, both Engines will tag the destination identically, though separately. Categories and keywords are centralized, so the auto-tagging condition on the IP address applies to all Engines.
Now let us imagine that you connect to one of the Engines and that you manually tag the mentioned destination as a Proxy server, overriding the auto-tagging rule. Now you find that the same destination is tagged as Mail server in one Engine and as Proxy server in the other, which is probably not what you want. Therefore, be careful when you apply tags manually (or with text files) to objects, because tags are not shared among Engines. To modify tags, a user must have a profile that allows the editing of applications and object tags.
Content local to Finder
A few types of items are stored in the computer that runs Finder. These items are not implicitly shared with any other copy of Finder or with any other Nexthink component:
Sessions
Store information on how to connect to Portal (user name, authentication method, etc.).
Custom actions
Launch external operations based on the data displayed in Finder. Custom actions can be exported and imported into another Finder (see below).
The case of alerts
When a user creates an investigation-based alert with Finder, the alert is stored in the centralized content manager and replicated in all Engines, but it is enabled only in the Engine to which Finder is connected. All other Engines will remain with the alert disabled until it is explicitly enabled. This mechanism prevents a user from exceeding the limit of enabled alerts in other Engines different from the Engine to which Finder is connected.
Exporting and importing content
Even if most of the content created by users with Finder is centralized, you can still share it manually by exporting items to the clipboard or to a file and, optionally, create a content pack. Because content is shared by all Engines instances connected to Portal, exporting content is especially useful in multi-environment setups with more than one Portal instance. It is common to create content in a pre-production environment and then export it to a production environment only once every item has been thoroughly tested.
Manually export and import your investigations, one-clicks, alerts, categories, metrics, scores, remote actions, and services from Finder.
Custom actions
Although local to Finder, custom actions are also exportable. Export your custom actions to XML files and share them with other copies of Finder:
Click the sprocket icon in the top right of the Finder window.
Select Custom actions... to display the list of available custom actions.
Select one or more entries in the list by clicking on them. Use Ctrl+click to select more than one entry, Shift+click to select a group of consecutive entries, or Ctrl+A to select them all.
Right-click your selection and choose Export... from the menu.
Type in a name for the XML file.
Click Save.
To import custom actions into Finder, click the Import... button at the bottom of the list of custom actions and select the file to import. If an imported custom action exists already in the list, it is duplicated.
Centralizing content via roles
Administrators can assign owned content such as investigations, one-click investigations, investigation-based alerts, and remote actions to other users by making them role-based. Once linked to a role, an item is seen by all the users playing that role and not just by the user that created the item. To add investigations, one-clicks, or alerts to a role, administrators typically use the manual method of exporting items to the clipboard.
Last updated