Filtering

While you will spend most of your time in Disco’s analysis views (see Analyzing Process Maps, Analyzing Statistics, and Analyzing Cases), which already provide a wealth of information about your process right after importing your data, process mining does not stop there. The power of process mining comes from being able to quickly and interactively focus on particular aspects or subsets of your process based on the analysis questions that you have.

The way in which you can zoom into your process based on your analysis questions is by using filters. Filtering is symbolized by the funnel symbol shown in Figure 1.

_images/filter-icon.png

Figure 1: Filter symbol in Disco.

In this chapter you find further details about which filters are available in Disco and how they work. Refer to Working with Filters to learn more about how to add, manage, combine, and re-use your filters.

Timeframe Filter

The timeframe filter enables you to focus your analysis on a certain time period. For example, imagine that you want to analyze four weeks of data to understand the typical process load for one month. Although your data set contains several months of data, you would like to restrict the considered timeframe from Monday 3 February 2011 until Monday 31 February 2011. The timeframe filter allows you to do just that.

_images/TimeframeFilter.png

Figure 2: Controls and options of the Timeframe filter.

Figure 2 gives you an overview of the options and controls that you have for the Timeframe filter in Disco:

Start of selected time frame (1), (2)

Choose the beginning of the timeframe that you want to keep in the filtered log by simply dragging the left handle (1) of the timeframe slider along the time axis. While you are moving the slider, the changing start time will be reflected in the simultaneously updating calendar sheet (2). It also works the other way around: You can explicitly select a specific date (browse through the months by using the left-pointing and right-pointing arrow buttons at the top) and time in the start time calendar sheet (2), and this will change the position of the start timeframe slider handle (1).

For example, in Figure 2 the start time has been set to 1 January 2011 at 09:00 o’clock.

End of selected time frame (3), (4)

Choosing the end of the timeframe works in the same way as choosing the start of the time frame, using the right handle (3) of the timeframe slider or the end time calendar sheet (4).

In Figure 2 the end time has been set to 31 January 2011 at 17:00 o’clock.

Visual feedback (5)
In the chart at the top of the configuration screen, you can see the currently covered timeframe highlighted in blue in comparison to the overall log timeline. The reference chart shows the number of active cases over time to give you a sense of how many of the cases are covered by your current selection. The chart that is used is the same one as you can find in the Overview statistics (see Overview Statistics for more information on the Active cases over time visualization).
Usage mode (6)
In the middle of the configuration screen you can determine what you want to do with the selected timeframe: For example, do you want to keep all cases that have been both started and finished between the selected start and end date? Or do you intend to select all cases that have been just started in the configured time period?
_images/UsageModes.png

Figure 3: When you change the usage mode, the blue visualizations adapt to help you understand the effect of the mode you are currently using.

To understand the usage modes, look at Figure 3. The blue visualization indicates which cases are kept in the current configuration: Every (grey or blue) horizontal bar represents one case. The horizontal axis represents the timeline, and the position of each horizontal bar shows the earliest and the latest event in relation to the global log timeline. The vertical bars represent your timeframe selection.

The blue bars tell you which cases will remain in your dataset after you apply the timeframe filter, depending on the currently configured usage mode. Here is a description of the Usage mode settings, (6) in Figure 2, that you can choose from:

Contained in timeframe
The default mode of the Timeframe filter, where only cases that completely lie within the selected start and end boundaries are kept.
Intersecting timeframe
Keeps cases that are overlapping (intersecting) with the selected timeframe. The reference point is the earliest and the latest timestamp in each case. So, even if nothing actually happened within (no events of the case actually fall into) the selected timeframe, the case will still be kept as long as it started before the end of the selected timeframe, (3), (4) in Figure 2, and ended after the configured start date, (1), (2) in Figure 2.
Started in timeframe
Keeps cases that are starting in the selected timeframe. This can be useful if you, for example, want to compare all orders that were started in March 2014 with the orders that were started in March 2015 (cohort analysis) - regardless of how long they were running in total.
Completed in timeframe

Keeps cases that are completed in the chosen timeframe. This mode is useful if you want to analyze, for example, all purchase orders that that were paid in a particular month.

Note

Note that the Completed in timeframe option (as well as the Started in timeframe option) only looks at the time of the occurrence of your last (or your first) activity per case. The Timeframe filter does not know anything about incomplete cases and you will need to combine the Timeframe filter with an Endpoints Filter if you have open cases in your data set that should be removed.

Trim to timeframe
The trim mode takes all the cases that intersect with the selected timeframe and cuts them off before and after the chosen time period (trims them). So, it removes all events that fall outside of the configured time period. This is the only timeframe filter mode that potentially changes a case (by cutting a part of the case off). All the other timeframe filter modes only give you different criteria to select cases. One typical use case of the Trim option is to remove Zero timestamps from your data set. [2]

Variation Filter

The variation filter is a great way to focus your analysis on either the most common or on the most exceptional behavior in your process.

We’ll use the purchasing process example again to explain how it works. In Figure 4 you can see the top frequent variants for the purchasing process data set. In Disco, a variant is an activity sequence pattern. This means that all cases that follow exactly the same activity sequence belong to the same process variant. If you are not yet familiar with variants, then you can learn more about them in the Cases view reference in Inspecting Variants.

_images/Variants-Snippet.png

Figure 4: The most frequent variants for the purchasing demo example.

In Figure 4, one can see that there are in total 98 different variants in the data set. The most frequent pattern, Variant 1, is followed by 88 cases (this corresponds to 14.47 % of all the cases in the log). The fifth-frequent is Variant 5, which is followed by 32 cases (5.26 % of all the cases in the log).

So, now let’s say that instead of viewing the process map for all the 98 different variants, you only want to see how the process looks like for the most common behavior. This is exactly, what the Variation filter allows you to do.

Figure 5 shows the configuration settings of the Variation filter. It has been configured to include only those variants that are followed by at least 32 cases in the log. In the case of the purchasing process example, this includes only Variant 1 – Variant 5 (see Figure 4).

_images/VariationFilter1.png

Figure 5: Settings of the Variation filter.

Lower limit (1)
The minimum number of cases that need to follow the activity sequence pattern of the variant to be passed through to the filtered log. In Figure 5, the minimum number of cases with the same activity sequence (siblings) has been set to 32.
Upper limit (2)
The maximum number of cases that are allowed per variant to remain in the filtered log. In Figure 5, all variants with more than 32 cases are included in the selection.
Coverage feedback (3)
To get a sense of how many cases in the log are covered by your current selection, you can check the pie charts at the bottom of the configuration screen. In Figure 5, one can see that with the selection of just the most frequent 5 % of the variants in fact 50 % of all cases (and 3 % of all events) would remain in the filtered log.
Case frequency histogram (4)

The histogram in the background indicates the number of cases that are included in the variant selection. The histogram typically has some kind of U-shaped form similar to the one you can see in Figure 5.

If you are wondering why the number of cases increases again towards the left side, then you need to keep in mind that there are a lot of unique variants (variants only followed by a single case), or variants that cover only two cases, etc. So, the left-most bar in the histogram covers all variants (and therefore all cases) that are unique.

Instead of focusing on the most common behavior, you can also zero in on the most exceptional cases, for example those that occurred only once or twice. In this case you would move the handle of the variation slider (1) to the very left and adjust the upper boundary (2) accordingly.

Note

The variation filter provides a controlled way of filtering common behavior for structured processes, where some activity sequence patterns are very common and others very rare. Often, 20 % of the variants make up 80 % of the cases. For unstructured processes, where you have many low-frequent variants, this is usually less useful.

Read more about the interactive simplification controls that you can use for any data set to adjust the level of detail in your discovered process map in the Map view reference Analyzing Process Maps.

The variation filter is a way to filter your data sets by grouping variants based on their frequency. However, you can also explicitly filter based on a specific selection of variants (for example, Variant 1, Variant 2, and Variant 4 - but not Variant 3). Refer to Attribute Filter to learn how variants can be filtered explicitly.

Performance Filter

The performance filter allows you to focus on cases in your data set according to certain performance criteria. For example, if you want to see all cases that exceed a specific throughput time (violating the service level agreement for your process) and find out in which part of the process these cases lose most of the time, then the performance filter helps you to do that.

_images/PerformanceFilter.png

Figure 6: Settings of the Performance filter.

In Figure 6 the configuration options for the performance filter in Disco are shown. To use the filter, go through the following steps:

Performance metric (1) and reference chart (2)

First, select the performance metric you are interested in. After you have selected the metric in (1), the reference chart (2) below will update and show the distribution for the metric you have chosen. Per default, the metric Case duration is selected and displayed.

The following process metrics are available:

  • Case duration. Time between the first and the last event in each case. The chart that is displayed in the background (2) is the Case duration chart from the Overview Statistics. Refer also to Case Statistics to learn more about case durations.
  • Number of events. The total number of activities that were performed in each case (including repetitions). The chart that is displayed in the background (2) is the Events per case chart from the Overview Statistics. Refer also to Case Statistics to learn more about events per case.

If you have start and complete timestamps for your activities in your data set [1], you can also use the Performance filter to look at the active time (time spent within an activity, i.e., between start and completion of an activity) and waiting time (inactive time spent between activities, i.e., between the completion of one activity and the start of the next activity) in the following way:

  • Case utilization. Ratio of active time with respect to the total case duration. If the case utilization is 100 %, then there was no waiting time at all. If the case utilization is 50 %, then half of the case duration was spent actively on performing activities while the other half was spent waiting. The chart that is displayed in the background (2) is the Case utilization chart from the Overview Statistics.
  • Total active time. The sum of all active times for the whole case.
  • Mean active time. The average active time block in the case (active time blocks are separated from each other by idle / waiting times, where no activity was performed at all). The chart that is displayed in the background (2) is the Mean activity duration chart from the Overview Statistics.
  • Maximal active time. The largest active time block in the case.
  • Total waiting time. The sum of all idle times for the whole case.
  • Mean waiting time. The average time for all idle time blocks in a case. The chart that is displayed in the background (2) is the Mean waiting time chart from the Overview Statistics.
  • Maximal waiting time. The largest chunk of idle time in the case.
Lower limit (3) and Upper limit (4)

Determine the minimum value for the performance metric you have chosen by dragging the handle (3) of the slider to the desired position. For example, in Figure 6 the chosen performance metric is Case duration and the label below the selection slider tells you that the current configuration uses all cases that run longer than 71 days and 15 hours.

The upper limit (4) determines the maximum value for the performance metric you have chosen. In the example in Figure 6 the upper limit is at its maximum value, and therefore includes all cases that run longer than 71 days and 15 hours.

_images/ExplicitPerformanceValue.png

Figure 7: You can set an explicit value as the lower or upper limit in the Performance filter by clicking on the Minimum or Maximum value control.

Instead of using the slider, you can also explicitly set a lower or upper limit by clicking on the minimum or maximum value indicator in the configuration screen as shown in Figure 7. This can be useful if you want to set the boundaries based on a specific service level agreement. For example, for the purchasing process we might have the expectation that the whole process should be completed within 21 days. So, instead of moving the slider (3) to a value as closely to 21 days as possible, in Figure 7 we have clicked on the Minimum duration value and provide the exact value of 21 days as the minimum value.

Coverage feedback (5)

The pie chart at the bottom gives you an estimate of how many cases (compared to the whole log) are included in your current selection. Together with the blue highlighting in the performance chart (2), this helps you to understand which portion of your data set you are currently focusing on. For example, in Figure 6 we can see that ca. 15% of the cases in our data set take longer than 71 days.

Note that the coverage feedback is an estimate and the precise percentage will only be shown after filtering. If you should get a different coverage feedback during the configuration of your filter, refer to “Why is the preview different from the % Cases after applying the filter?” for an example.

Extend range (6)

The values that you can select in the Performance filter range from the minimum to the maximum value that were observed in your data set. The Extend range option extends the lowest value from the minimum value to 0.

This can be useful if you want to apply the Performance filter after other filters that have shortened the actual case durations (like the Endpoints Filter in Trim mode). As an alternative to using the Extend range option you can also refer to the reference-filtering-troubleshooting-wronginput section.

Endpoints Filter

The Endpoints filter allows you to determine what should be the first and the last event in your process. We’ll use an example case from the purchasing process (see Figure 8) to show you how this works.

_images/caseExample-EndpointsFilter-DiscardMode.png

Figure 8: Example case with highlighted start and end events.

In the case shown in Figure 8, the first event corresponds to the activity Create Purchase Requisition and was performed by Anna Kaufmann. The last event corresponds to activity Analyze Request for Quotation and was performed by Francois de Perrier. In total, there are 4 events in this case. You can also see the timestamps for each of the activities, and there could be more attributes related to the case as well. See Analyzing Cases to learn more about how you can inspect individual cases in Disco.

The regular end of the purchasing process is Pay invoice, so we can see that the case in Figure 8 has been stopped earlier—probably because the purchase requisition has not been granted. If we see that many of the submitted purchase orders do not go through, this might hint that people don’t know what they are allowed to buy. We might need to offer additional training, or to update the purchasing process instructions.

To investigate cases based on their start and end event values, you can use the Endpoints filter as shown in Figure 9.

_images/EndpointsFilter-DiscardMode.png

Figure 9: The Endpoints filter in Discard cases mode.

The following controls are available in the settings screen:

Event column to be used for filtering (1)
Most of the time, you want to filter based on the start and end Activity in each case. However, you can also use other event columns, such as the Resource column (e.g., to keep all cases that were started by Anna Kaufmann), or any other attribute column from your data set.
Usage mode (2)
The default usage mode is Discard cases. In this mode, the very first and last activities (or attribute values) of the case are used to determine whether the case should be kept or not. In the Trim longest and Trim first modes, you can freely determine the start and end events for your process. You can find an example that involves trimming later in this section.
Start event values (3)

Select the values that you want to allow the cases to start with from the list of available start values. In Figure 9 you can see that all the cases in the purchasing example actually start with the Create Purchase Requisition activity. So, there is only one start activity to choose from.

Note that in Discard cases mode, only the values that occur for the first event in the case are shown in the list of start event values (3) and only the values that occur for the last event in the case are shown in the list of end event values (4). If you find yourself looking for activities in the middle of the process, you probably want to use the Endpoints filter in one of the Trim modes (see an example further below in this section).

End event values (4)

Select the values that you want to allow the cases to end with from the list of available end values. For example, in Figure 9 the end values were configured in such a way that only cases that either end with the Analyze Purchase Requisition or with the Analyze Request for Quotation activity will be kept. All cases that end with the regular Pay invoice activity will be discarded.

Another very common use case for the Endpoints filter in Discard cases mode is to clean the data set from incomplete cases: In many situations, you will get a data set that contains some cases that are incomplete because they were either started before the data extract begins, or they were not yet finished when the data was extracted. To clean up your data you can remove those incomplete cases from the log by selecting only the valid start and end activities in the Endpoints filter.

Select all (5)
Select all values in the list (3) or (4) at once. This can be handy if you work with large lists but only want to deselect a few values from that list.
Deselect all (6)
Deselect all values in the list (3) or (4) at once. This can be handy if you only want to select a few values from a large list.
Invert selection (7)
Use this button to deselect all currently selected values in list (3) or (4) and vice versa (all currently deselected values will be selected).
Search (8)

Reduce the displayed list of values based on specific letter combinations or words that you type in the search field. This is particularly useful if you have hundreds or thousands of different values for an attribute, and finding the value you are looking for manually is cumbersome.

Note that once you have restricted the list of values through the search, then the Select all (5), Deselect all (6), and Invert selection (7) controls only operate on the values that are currently displayed. You can clear the search to use them on the full list again.

Now, let’s take a look at a scenario where we would want to use the Endpoints filter in Trim mode. Imagine that you want to focus your analysis of the purchasing process on the phase, where the purchase request is created and approved. Afterwards, the quotation phase with the supplier starts and we are not interested in that part of the process at the moment (see Figure 10).

_images/TrimFilter-1.png

Figure 10: The part of the purchasing process we are interested in. The activity Analyze Request of Quotation is the last activity before the process moves into the next phase.

We can use the Endpoints filter to focus on this part of the process in the following way. We add an Endpoints filter and change the filter mode to Trim longest (the difference between Trim longest and Trim first will be explained shortly), which now brings up the full list of activities from our process in the start and end event values (not just the ones that occur as the very first or very last one). We then select activity Analyze Request of Quotation as the boundary activity, after which we want to cut off the process (see Figure 11).

_images/TrimFilter-2.png

Figure 11: In Trim mode, everything that happens after the selected end activities (here Analyze Request of Quotation) will be cut off. Similarly, all activities that happen before any of the selected start activities can be cut off (not used in this example).

After applying the filter, the process has been reduced to the desired segment. Activity Analyze Request of Quotation is now the new end point in the process (see Figure 12).

_images/TrimFilter-3.png

Figure 12: After trimming, the process is cut to only show those steps that happen before Analyze Request of Quotation.

The difference between Trim longest and Trim first only comes into play if the selected end boundary activity can occur multiple times in a single case. We can see that this happens for activity Analyze Request of Quotation. For example, in Figure 13 we can see that case 39 went through three occurrences of the process step Analyze Request of Quotation.

_images/TrimFilter-4.png

Figure 13: The Trim longest mode cuts off everything that happens after the last occurrence of the selected end activities (here Analyze Request of Quotation).

If we wanted to cut off our process segment after the first occurrence, we could use the Trim first mode as shown in Figure 14.

_images/TrimFilter-5.png

Figure 14: To cut off everything after the first occurrence of the selected end activities, use the Trim first mode.

After applying the filter, we can see that now the process map has changed, because all the loops around Amend Request for Quotation are not included anymore. Instead the process segment focuses on everything that happens until the first occurrence of Analyze Request of Quotation (see Figure 15).

_images/TrimFilter-6.png

Figure 15: Process map after applying the Endpoints filter in Trim first mode.

When we inspect the same case 39 again in the filtered data set, then we can also see here that only the first occurrence of Analyze Request of Quotation has been preserved (see Figure 16).

_images/TrimFilter-7.png

Figure 16: The same case (case 39) that was shown in Figure 13 after applying the Endpoints filter in Trim longest mode is now shorter after applying the same filter in Trim first mode. There are also fewer variants in the resulting data set, because the various loop patterns from the process segment are not included anymore.

The Trim mode in the Endpoints filter is often used to focus on certain subsets of the process more closely in the analysis phase. However, the Trim mode can also be used for clean-up purposes if your end activities are not guaranteed to be the last event in the process. For example, sometimes you have a dataset where after a successful completion event there may still be some kind of comment activities, thus making it impossible to use the Discard cases option for clean-up without removing the comment activities first. Use Trim to directly indicate where your process starts and ends, and it will throw away the rest.

Attribute Filter

The Attribute filter does a lot of different things. You can use it to split your data set based on a particular attribute, but also to filter cases based on the presence or absence of activities, to filter case IDs and variants, or to remove individual activities or attribute values. Figure 17 shows the controls and options that are available in the configuration settings screen.

_images/AttributeFilter.png

Figure 17: Settings of the Attribute filter.

Filter by (1)

You can choose to filter based on the Activity name, the Resource column, or any other attribute column from your data set. Depending on the event column that you choose, all the observed values for that particular column will appear in the list (3).

At the very bottom of the list you can also choose to filter by Case ID or Variant, which will populate the list (3) with the case IDs or variant IDs, respectively.

Filtering mode (2)

The following three filtering modes are available:

  • Keep selected. Use this filtering mode if you want to remove events that do not have one of the selected values for the Event column (1) that you have chosen. This can be used for the clean-up of unimportant activities, and to focus your analysis. For example, in Figure 17 the activities Analyze Quotation comparison Map, Choose best option, and Create Quotation comparison Map would be removed from your data set.

    You can also use this option to split out your data set for a particular case attribute value. For example, if you have a Country attribute in your data set, you can use the Attribute filter to compare the processes between France and Germany. First, select the France value for the Country attribute and use the Copy and filter button (see also Applying Filters). Then, filter based on the Germany attribute value and compare the two processes.

  • Mandatory. Use the mandatory indicator to determine which activities, or resources, countries of origin, product types, etc. - depending on what you have chosen in (1), must be present (occur somewhere in the process) to keep a case in the filtered data set.

    Often, you want to zero in on just those cases where one particular activity occurred. For this scenario, you can best use the short-cut from the Map view: Click on the activity in the process map, and then press the Filter this activity... button to directly get to a pre-configured Mandatory Attribute filter. Learn more about this shortcut in the Map view reference section Filtering Activities from the Process Map.

  • Forbidden. Use the forbidden indicator to determine which activities, or resources or whatever you have chosen in (1), must be absent (not occur anywhere in the process) to keep a case in the filtered data set. The Forbidden mode works in the opposite way compared to the Mandatory mode.

    Imagine, for example, that you want to remove all cases in the purchasing process where a dispute had to be settled with the supplier. The quickest way to achieve this would be to use the Filter this activity... short-cut form the process map and then change the mode from Mandatory to Forbidden.

Event values (3)
Choose the event values that you want to keep, make mandatory, or make forbidden—depending on the filtering mode (2) you are using.
Select all (4)
Select all values in the list (3) at once. This can be handy if you work with large lists but only want to deselect a few values from that list.
Deselect all (5)
Deselect all values in the list (3) at once. This can be handy if you only want to select a few values from a large list.
Invert selection (6)
Use this button to deselect all currently selected values in list (3) and vice versa (all currently deselected values will be selected).
Search (7)

Reduce the displayed list of values based on specific letter combinations or words that you type in the search field. This is particularly useful if you have hundreds or thousands of different values for an attribute, and finding the value you are looking for manually is cumbersome.

Note that once you have restricted the list of values through the search, then the Select all (4), Deselect all (5), and Invert selection (6) controls only operate on the values that are currently displayed. You can clear the search to use them on the full list again.

If you want to explicitly filter a set of selected case IDs, or a selection of variants, you can go to the very end of the Filter by drop-down list (1) and select the Case ID or Variant option there (see Figure 18).

_images/AttributeFilterVariants.png

Figure 18: Next to filtering for arbitrary attributes and activities, the Attribute filter also allows you to select cases and variants.

For example, in Figure 18 Variant 1, Variant 2, and Variant 4 are selected. One scenario, where filtering a specific set of variants can be useful is when these variants reflect your ideal process and you would like to see how many cases follow the expected process (see also Filter Short-cuts for another approach to quickly get to the “First Time Right” process).

Follower Filter

While the Attribute Filter allows you to select cases based on the occurrence (Mandatory mode) and non-occurrence (Forbidden mode) of activities or other event values, the Follower filter goes one step further: It lets you specify a simple process pattern based on the so-called follower relation. Figure 19 shows the main controls that are available in the filter settings.

_images/FollowersFilter.png

Figure 19: Settings of the Follower filter.

Filter by (1)
You can choose to filter based on the Activity name, the Resource column, or any other attribute column from your data set. Depending on the event column that you choose, all the observed values for that particular column will appear in the list (2) and (3).
Reference event values (2)
The events that provide the reference point for the process pattern that you want to define.
Follower event values (3)
The events that should (directly or eventually, or never directly or eventually) follow the reference event according to the process pattern mode (4).
Filtering mode (4)

Four filtering modes are available: eventually followed and directly followed as well as their negations (never eventually followed and never directly followed). The difference between the process pattern eventually followed and directly followed is illustrated in Figure 20:

_images/FollowsEventuallyVsDirectly.png

Figure 20: The directly followed mode filters based on process patterns, where events occur directly after each other. The eventually followed mode determines whether events follow each other some time in the future, which means that other events can occur in between.

  • Eventually followed. The eventually followed mode allows you to specify a follower pattern in which a certain activity (or other event value) (3) must follow the reference event value (2) sometime later in the same case (other events can be in between the reference and the follower event).

    In Figure 20 an example case from the purchasing process is shown. We assume that Create Purchase Requisition has been defined as the reference activity (2). If any of the activities Analyze Purchase Requisition, Create Request for Quotation Requester Manager, or Analyze Request for Quotation (or all of them) would be set as a follower activity (3), this case would remain in the data set after applying the filter in eventually followed mode.

  • Directly followed. The directly followed mode requires that a certain activity (or other event value) (3) must follow the reference event value (2) directly afterwards in the same case.

    Again assume that in Figure 20 Create Purchase Requisition has been defined as the reference activity (2). Now, only if Analyze Purchase Requisition would be be set as a follower activity (3), then this case would remain in the data set after applying the filter in directly followed mode.

    Often, you want to focus on just those cases where one particular path (between activity A and activity B) was followed. For this scenario, you can best use the short-cut from the Map view: Click on any path in the process map, and press the Filter this path... button to directly get to a pre-configured Follower filter. Learn more about this shortcut in the Map view reference section Filtering Paths from the Process Map.

  • Never eventually followed. The never eventually followed mode works in the opposite way to eventually followed: Instead of keeping all cases that match the eventually followed process pattern it will remove them.

  • Never directly followed. The never directly followed mode works in the opposite way to directly followed: Instead of keeping all cases that match the directly followed process pattern it will remove them.

4-Eyes filter (5)

If you enable this option, an additional requirement can be added to the Follower filter based on another dimension. The values for the events in the follower pattern can be required to be either equal (the same value) or different (different values) for the chosen event dimension (5).

One typical use case is to specify a 4-eyes requirement (to ensure so-called segregation of duties) for resources when the Follower specification is based on activities. For example, one could specify that the approval of a travel request cannot be completed by the same person who initially submitted the request. Another typical use case is the filtering of cases with repetitions.

Time-constraint filter (6)

You can also specify an additional time constraint regarding the activity pairs matched by your follower pattern. The time constraint can be either that the events should be more than the indicated amount of time apart (“must be longer than”) or that they should be less than the indicated time apart (“must be shorter than”).

This time-between filter option is very handy to check arbitrary time constraints within the process (“Getting from activity X to activity Z should not take longer than...”) while preserving the full case context. You could often answer the same questions using a combination of the Trim mode in the Endpoints Filter and the Performance Filter. However, this time-between option in the Follower filter keeps the case intact and only selects or discards cases based on the time criteria.

Select all (7)
Select all values in the list (2) or (3) at once. This can be handy if you work with large lists but only want to deselect a few values from that list.
Deselect all (8)
Deselect all values in the list (2) or (3) at once. This can be handy if you only want to select a few values from a large list.
Invert selection (9)
Use this button to deselect all currently selected values in the list (2) or (3) and vice versa (all currently deselected values will be selected).
Search (10)

Reduce the displayed list of values based on specific letter combinations or words that you type in the search field. This is particularly useful if you have hundreds or thousands of different values for an attribute, and finding the value you are looking for manually is cumbersome.

Note that once you have restricted the list of values through the search, then the Select all (7), Deselect all (8), and Invert selection (9) controls only operate on the values that are currently displayed. You can clear the search to use them on the full list again.

Footnotes

[1]Refer to Import for further details about the import configuration and about how to deal with multiple timestamps.
[2]Read the following article to learn more about Zero Timestamps and what to do about them: http://fluxicon.com/blog/2016/02/data-quality-problems-in-process-mining-and-what-to-do-about-them-part-3-zero-timestamps/.