Have you been using Operations1 for a while and your tables are gradually getting longer and longer? Have you just started using Operations1, but have already noticed that even with a small number of documents it can be difficult to identify the relevant document to work on with just a few clicks? Do you have problems finding what is important at first glance, as this number of documents can already result in a considerable number of reports or orders?
Then how is it possible to see exactly the documents, orders, reports, tasks, etc. that are relevant to you with just a few clicks?
The use of class characteristics and filters is the answer to these challenges! You can use them to structure and restrict views.
In this best practice article, we would like to explain how you can use class characteristics and filters to answer these questions. To do so, we will first explain which settings need to be considered for correct filtering, as well as which considerations should be made when structuring, before explaining the implementation of filtering in the final chapter.
Table of contents
Building a structure in Operations1
To build your own structure in Operations1, we recommend using classes and class characteristics.
The overarching term "classes" describes a collection of class characteristics. You can hence create several classes and add any number of class characteristics within them.
To find out which class structure is suitable for you, you should first ask yourself a couple of questions:
Which activities are supported with Operations1?
Are these activities carried out by different departments or at different locations or are they specifically tailored to one department and/or one location?
Are different resources reused for these activities or are similar products/assemblies associated with them?
Are some activities combined, for example for a customer order?
Are there certain groups of people who can only be assigned to one of these levels, such as a location or an area of activity?
The answers to these questions can help to define the different levels of classes and their relationships. It is advisable to use your own company structure as a guide when determining the appropriate class setup.
The "location" class is often selected as one of the upper levels, to which various "departments" or "activities" are linked, which in turn can be assigned to various "machines", "workstations" or "products". In addition, a distinction is often made between "document types", which cannot be assigned to the hierarchy of the other classes, but stand parallel to them.
The example shows that classes and characteristics do not necessarily follow a hierarchy, but can represent a hierarchy through intelligent linking.
The following article explains how you can now create classes and class characteristics using the structure you have developed: Create classes and class characteristics | Operations1.
Start with a simple structure and work your way up to your target structure step by step. Creating classes and class characteristics for the first time can be complex - therefore do not hesitate to contact your Customer Success Manager for support.
Using your structure for searching
Once you have defined a structure, you can search each table based on it. However, the first time you try this, you are likely to find that clicking on a characteristic does not yet return a search result. The missing step: You must carry out the classification.
Ensuring classification for simple searches
In order to use class characteristics for searching, all objects must be classified with them. The reason for this is that the search for class characteristics always requires a 100% match. If you search for a specific characteristic, all objects that have been classified with this characteristic are displayed. If no object has been classified with this characteristic, the results table will be empty.
You can find out how to assign class characteristics to various objects in Operations1 by reading the following article: Classify and organize documents, media and materials according to structural classes and classifiers | Operations1.
As a best practice, we recommend that you ensure that all class characteristics are assigned upon creation of a new object, such as a document, order or task. Most tables offer the option of mass classification, as used in the GIF above. If you add class characteristics at a later date, you can use this function to quickly add new characteristics to all desired objects.
Configuring filter settings for more complex searches
As soon as all objects are correctly classified, combinations of several class characteristics can also be used for a search.
The side panel for selecting class characteristics contains some helpful additional functions that enable a fairly sophisticated filtering process.
First of all, it is important to understand that the side panel also filters down if different characteristics are linked to each other by so-called "pivot classes". When creating classes, you can specify in the settings that, for example, the maintenance department belongs to the location Frankfurt. Now only the location Frankfurt is displayed when the characteristic Maintenance is selected. To temporarily bypass this function, you can remove the tick from the "Only connected" checkbox.
By default, the connection works according to a "logical and" (intersection) and can be used to build a hierarchy between characteristics. Alternatively, the setting can also be changed to a "logical or" (union). This changes the filtering of the characteristics as follows:
Intersection: show all characteristics that are assigned to department A AND department B. In the example GIF, there are no locations that are assigned to both departments.
Union: Show all characteristics that are assigned to department A OR department B. In the example GIF, the Frankfurt location is assigned to the Maintenance department and the Berlin location is assigned to the Assembly department.
Please note: This functionality refers solely to the side panel, not to the filtering of objects in the selected table view!
Once the various relevant characteristics have been selected, you can now search for the actual objects. Here, too, the default search uses an intersection of all selected characteristics. If maintenance in Frankfurt is selected, the system searches for properties that are classified with both the characteristic "Maintenance" and the characteristic "Frankfurt". Alternatively, this can also be changed to a union so that all properties classified with either the characteristic "Maintenance" or the characteristic "Frankfurt" but not necessarily with both are searched for.
Furthermore, there is an option to include upper and lower results. This refers to the displayed order of the classes and is a simplified variant to achieve a logical Or.
Including upper results is defined as follows: Search all objects that are classified with the selected class characteristic OR with one of the characteristics displayed above it.
Including lower results replicates this principle: Search for all objects that are classified with the selected class characteristic OR with one of the characteristics displayed below it.
This type of filtering only works for linked characteristics, as it also affects the display in the side panel - as described first in this section.
Attention here as well: If the display sequence is changed, this also has an effect on the upward and downward filtering, whereas nothing changes in the combinatorics of union or intersection.
Excursus: Inheritance of class characteristics
The search for objects with certain class characteristics requires that the object is also classified with these characteristics. If, for example, you are looking for a document from the maintenance department at the Frankfurt location, the document must be assigned both the Frankfurt characteristic and the maintenance characteristic for it to be found.
Even if a hierarchy seems logical, the classification with characteristics must be made explicitly for all existing levels of classes.
This can be time-consuming with many different objects. For example, if you combine several documents in one order, both the documents and the order must be classified correctly to ensure a smooth search mechanism.
It is therefore helpful to understand the different forms of inheritance for all areas in the platform:
Orders and rules: Orders and rules must always be classified manually. When duplicating orders or rules, the classification of the original object is transferred to the duplicate. When creating a new order or rule, it is also possible to transfer all class characteristics from all assigned documents.
Documents: Documents must always be classified manually. When duplicating documents, the classification of the original document is transferred to the duplicate.
Reports: Reports automatically adopt all classes of the documents they are based on. This means that documents pass on their classification to the reports created from them. Class characteristics can still be adjusted before the report is started or during processing. No further changes can be made to completed reports.
Tasks: If a task is created during report processing, the task takes over the classification of the report. This means that reports pass on their classification to the tasks created from them. If a task is created without reference to a report, it must always be classified manually.
Media and materials: Media and materials must always be classified manually. Even when converting from local to global, no classification is applied, meaning that subsequent classification must take place.
Applying filters to restrict visibility
Even after classification, the visibility of objects in Operations1 does not immediately change. The side panel allows you to filter by class characteristics and display only selected objects with just a few clicks.
But what can you do if you always have to repeat the same selection in different tables? Or if you already know which selection your colleagues should make and you want to simplify their work?
In this case, it is a good idea to first create saved filters by saving the selection you have made under a meaningful name. When saving a filter, the selection of section or union as well as upwards or downwards filtering is also saved.
Once you have created a saved filter, you can use it to replicate the same selection of class characteristics with just a few clicks. As soon as you select a saved filter, you will notice that it is not only applied to the table view you are currently in, but also to all other tables in the current view.
When creating new saved filters, it is advisable to save them from the table in which you can easily understand the result of the respective filter. This allows to see the search results of the selected combinatorics of class characteristics during the initial setup and to determine directly whether this meets your expectations. Name your filters as clearly as possible so that it is clear which result can be expected with which filter if there are several filters.
You can now select and remove the filters you have created yourself, but you can also assign them directly to one or more users via the user table. Colleagues who may not yet be fully familiar with the class characteristics do not have to experiment themselves, but can start directly with a view of only those objects that are relevant to them.
With this procedure, you have already created a view restriction for all colleagues. However, if you now want to prevent all or individual class characteristics from being deselected you can restrict these filters. As a result, individual characteristics can no longer be deselected and users are "locked in" to the previously set views via the filters. It is also no longer possible to change filters via the side panel in the tables.
To set up restricted filters, we recommend the same procedure as before: First create a filter from the table in which you can easily understand the filter result and save it under a name that is as meaningful as possible. As soon as you are satisfied with the result, switch to the settings and open the list of all filters. From there, you can customize your newly created filter so that some or all class characteristics are locked.
Summary and future development
In this article, we have explained how you can use class characteristics and saved filters to restrict views for different users.
Please note that this procedure is purely a view restriction. This means that the system does not restrict access.
You are therefore still able to share a link to an object in Operations1 with colleagues who would otherwise not be able to see this object in their table view due to filters that have been set. The recipients of the link can still open the object according to their roles and edit it if necessary.
If you require access control with a system-side check of access rights, you should take a look at the current development status of our access control.
If this article has helped you, please leave us a short feedback using the emoji buttons at the bottom of the page. Your feedback will allow us to assess the extent to which these and other articles are of interest to you.
A small preview already today: A best-practice article on system-side access control - building on the knowledge from this article - will follow!