All versions of this manual
X
Welcome to Linkurious user manual v4.1.9. Use the menu to access other documentations.
  1. Introduction
  2. Spaces
  3. First visualization
    1. At first glance
    2. Create a new visualization
    3. Inspect data
  4. Manage visualizations
    1. Open rename delete
    2. Moving visualizations
    3. Share
    4. Duplicate
  5. Queries
    1. Creating queries
    2. Tagging queries
    3. Running and managing queries
  6. Custom actions
  7. Search
    1. Searching for nodes
    2. Searching for edges
    3. Advanced search
    4. Advanced syntax
  8. Manipulating the graph
    1. Auto-save
    2. Select nodes and edges
    3. Expand nodes
    4. Node Grouping
    5. Edge Grouping
    6. Lasso
    7. Hide
    8. Layouts
    9. Pinning nodes
    10. Undo/redo
    11. Shortcuts
    12. Publish
    13. Export
  9. Design
    1. Captions
    2. Nodes color
    3. Edges color
    4. Nodes size
    5. Edges size
    6. Icons
  10. Filters
    1. Filter panel
    2. Timeline
  11. Comments
    1. Comments panel
  12. Edit data
    1. Edit properties and categories
    2. Create nodes and edges
    3. Delete nodes and edges
  13. Geography
    1. Geographic data
    2. Display a geographic map
  14. Alerts
    1. Setting up alerts
    2. Alert creation example
    3. Alerts Navigation
    4. Investigating cases
    5. Lexicon
  15. Guest Mode
 

Alerts: Setting up alerts

Setting up Alerts

In order to create an alert, navigate to the Alerts section from the top navigation menu and then click on the Alerts Dashboard button.

The alerts dashboard, where you can manage the different alerts created.

When on the alerts' dashboard, simply click on the Create an alert button which will re-direct you to the alert creation form page.

The alert creation form.

Only users with the right to create alerts can access the form.

General Settings

Alerts have general settings that concern their frequency, sharing options and more. These settings are spread on the top and bottom of the creation page.

Name and Description

On the top of the page, users are asked to enter the alert's name and description. The alert name is a mandatory field. The alert description is optional and can be used to give context on the alert's usability and purpose. The description of the alert can be viewed on the Unified case list by hovering over the alert title or opening the case preview where analysts will be investigating their cases.

Frequency, sharing options and enabling the alert

By default the alert, when enabled, will run every hour. It is possible though to adapt the frequency based on specific needs (for example the frequency of database updates).

We advise you to not go below the hourly frequency if your alert is too complex.

If the sharing options of an alert are not altered, it is only visible to its creators and Admin users. In order to make it visible to users,sharing options should be activated. This can be done by clicking on the Share alert toggle. Users are then asked to choose between sharing the alert with all users or one or more groups that have access to the datasource.

If an alert is shared via one of the above options, only users with "process alerts" or “create and process” rights will access it.

Finally, an alert will run only when activated. This can be achieved by clicking on the Enable alert toggle.

Saving Alerts

As creating an alert can be a complex process, users may have to test patterns and queries using the Linkurious Enterprise query system or consult investigators to ensure the consistency of the data returned. Therefore, there is the possibility to save an alert at any step during its creation.

Once the alert title is complete, the alert can be saved by clicking on the Save button (for your alert to run properly the target and at least one model should be correctly filled in). In case of pending errors within the alert (either on one of the models or on the attributes query), a window will exhibit the detected errors/warnings. There will exist the possibility to return to the alert creation page or continue with saving the alert.

In order for an alert to function properly, both for models and case attributes, the below criteria must be met:

  • The target of the alert must be specified.
  • The alert must have at least one error-free model using the defined target.
  • The attribute query must be valid(not include any syntax errors).
  • The columns must be correctly configured with an existing term in the return clause of the query. If all these criteria are met, once the alert is saved, it will run for the first time. If some of the above are not met, given that one functioning model is included in the alert it will still run. The system will first generate the cases and then, once all the cases are found, calculate the attributes for each of them.

When the alert is enabled in the setting, the alert can be saved and run by clicking the Save and Run button.

Alerts performances

Running an alert can be a heavy process. Depending on the alerts' properties, users could notice the interface slowing down for a few minutes while an alert is running. We recommend scheduling the run of alerts in production outside of business hours to allow for a seamless experience.

Subsequently, many parameters can affect the performance of alerts. In order to optimise the performance of your alerts, we recommend taking into consideration the following points:

  1. Models and preprocessing steps: The number and complexity of models or steps and the size of your dataset

    The performance of an alert to run is directly related to the queries you will make on the database. Each data preprocessing step or model you configure for an alert will run directly on your entire dataset. Therefore, the more complex the query is (e.g. because it will have to cross the whole network) or the more results it will return, the longer your alert will take to run.

Please note that using the Neo4j GDS library in an alert's preprocessing steps can be costly in terms of system resources and impact LKE performance depending on the complexity of the steps.

  1. Case attributes: The number of columns configured and the complexity of the query that will calculate the custom attributes

    The performance of the query that calculates the case attributes depends on the performance of the system the database is installed on. If the database is running on an undersized server, the computation will be slowed down.

  2. System: The configuration of the system on which Linkurious Enterprise runs The performance of Linkurious along with your database are directly related to the configuration of the system they are installed on. You can consult the Linkurious installation requirements for more information.

Example: For an alert of 5 models with a case attribute query that will generate 10 columns, it takes 8 minutes to generate 5000 cases on a system with 5GB of RAM and 2 CPU.

Once the alert has run, its cases can be found on the Case List and the Unified case list.

Data preprocessing, Models and Target

Target Field

In order for cases to be deduplicated properly, users have to set a target for their alert. The target is the entity used to deduplicate and group pattern occurences. The value of the target can be anything and it will have to be used in all the models that will be added to the alert.

You can set as a target a node, an edge, multiple nodes, multiple edges or a subgraph but no scalar values or any type of data stored in entities.

Models

The models of an alert are the detection patterns which users set. These patterns are called models. Each pattern has to be specified within a model using a query language (either Cypher or Gremlin, depending on your datasource). To create a model, click on the add a model button.

The model creation form.

The model name and model query are mandatory fields and are needed in order to save a model. The model query should be a read query. In case the user writes a write query, saving the model will not be possible. Write queries can instead be input as data preprocessing steps (see below). Once the model is successfully saved, it will become visible on the list of models on the alert creation page. From there, if the model has any syntax errors or if the target is not found within the model, users will be able to see them. Consequently, users are able to edit and or delete models by clicking on the corresponding buttons.

Incomplete models or models with errors are flagged in the alert creation page.

Complete model error in the template creation form.

Data preprocessing steps

Data preprocessing steps are a series of queries used to write to the database in order to prepare data for the alert before models are run. Each query has to be written (using either Cypher or Gremlin, depending on your datasource), and it is considered a step and they are run sequentially before any models.

Data preprocessing step creation form.

Step name and query are mandatory. Only write queries may be used in preprocessing steps. Steps are run in alphabetical order, sequentially.

Data preprocessing can be used to enrich node and edge properties (see an example) and for more complex operations requiring multiple steps. Users can also use the Neo4j Graph Data Science Library to run graph algorithms such as computing global scores.

Common uses for GDS will usually require the user to create multiple steps and run estimations to prevent performance issues.

Case Attributes

Once the models are created for an alert, cases will be returned once it has run. However, an analyst might need to access further information on cases in order to make informed decisions on their criticality.

To help prioritise and assign the most important cases to investigate, attributes can be created for each case. These attributes can be used to help prioritise cases (e.g. by calculating a "risk score"), to display information that makes it easy to assign cases to investigator (e.g. by displaying the type of fraud used), or to display important information about the target of the alert for quick decision making.

There are two types of syntax errors in the attribute creation query: the errors on the Linkurious Enterprise query template syntax and the errors related to the query language. These errors will be notified when saving the alert but are not blocking it.

In order to set up the case attributes, a query has to be written (using either Cypher or Gremlin, depending on your datasource). This query can either call directly or perform calculations on the data of a case. Once the query is written, columns that will appear in the lists of cases, need to be configured. In order for the above to be done, click on the add a column button and fill in the corresponding fields:

  • Title(mandatory field): the name of the column that will be visible in the case list
  • Term: the term returned in the return clause of the query
  • Type: the type of data returned in order to facilitate the sorting of cases, it could be:
    • String: To be used for attributes that are of type text (value's max length is 250 characters).
    • Number: To be used for attributes that are of type number (numbers are stored with at most 7 decimals).
    • Currency: To be used for attributes that are of type number and should be treated as monetary values (currency are stored with at most 7 decimals). Once applied, two additional fields appear which should be filled:
      • Symbol (Max. length of 10 characters): It represents the currency symbol
      • Format: It represents how the currency value should be formatted:
        • [Symbol] #,###.##: Currency symbol is displayed first, comma is used as thousands separator and dot as decimal separator.
        • #.###,## [Symbol]: Currency symbol is displayed last, dot is used as thousands separator and comma as decimal separator.
        • # ###,## [Symbol]: Currency symbol is displayed last, space is used as thousands separator and comma as decimal separator.

In order for the columns to be properly displayed, the type of the case attribute fetched from the query has to match the one you choose as a type.

The title field is mandatory.


IMPORTANT

Please note that users of alerts who don’t have access to specific node categories and/or edge types can still access this information in the case attributes if the created queries return them. They will not see the nodes and/or edges in the visualization/case view but the data will still be displayed in the alert columns.


Go to the next section to follow a complete example of an alert setup.