--- title: "Tutorial P2P - Maverick Buying (Skip)" url: "https://docs.noreja.com/en/article/noreja-smart-data-forge-tutorial-p2p-maverick-buying-skip" language: "en" last_updated: "2026-09-22T10:49:23.765Z" --- # Tutorial P2P - Maverick Buying (Skip) > **TL;DR**  > **Goal:** Generate cases in which certain requesters bypass an approval path that is actually intended.  > **Prerequisites:** `Config 1 – Basis` is loaded and the approval logic with `DUAL` and `DIRECT` paths is in place.  > **Result:** For the requesters `Kaya` and `Braun`, the intended `DUAL` approval branch is skipped in 80% of the relevant cases and the deviation is flagged. ## The business question A typical compliance question in the purchase-to-pay process is: **Are orders carried out even though the approval intended for this transaction was bypassed?** This behavior is often considered under **maverick buying**. For our synthetic example, we assume that the requesters `Kaya` and `Braun` in particular are conspicuous. If the regular `DUAL` approval path were intended for one of their transactions, it should be deliberately bypassed in a portion of the cases. ## Desired data picture In the normal case, the process looks, in simplified form, like this: `bestellanforderung` → `freigabe_a` + `freigabe_b` → `bestellung` In the maverick-buying case, by contrast, the following should arise: `bestellanforderung` → `bestellung` even though the `DUAL` approval path was originally intended for this case. The two approval objects are missing in this case. It is precisely this missing process pattern that should later become visible in Noreja. ## Important: `DIRECT` is not automatically maverick buying Our `Causal Chain` already has a regular `DIRECT` path. This means: A case for which the XOR decision selects `DIRECT` from the outset is **not a deviation**. The direct path is part of the intended process model. Maverick buying only arises when: - `DUAL` was actually selected for the case, - the case should therefore have traversed the approval path, - an additional rule then deliberately skips this approval path. This distinction is important because we later want to distinguish in the analysis between a **permissible process variant** and an **undesired deviation**. ## Why do we use `Team bypass`? Open: `04 Special Behaviour` There, the Smart Data Forge offers, among other things: `Overjump (skip a slot)` and `Team bypass (skip a branch for matching cases)` . In business terms, our maverick-buying scenario is a **bypassing of the approval**. Technically, however, we use `Team bypass` here, because it is not just a single slot that is to be skipped, but the complete `DUAL` branch with its approvals. For this, `Team bypass` can identify a branch by means of a branch owner and skip it for cases that meet a certain condition. ## 1\. Creating a new deviation rule ![](https://cdn-assets.productfruits.com/360fc317-2742-4ac6-a1c6-65f63bd9cc22) Under `Add deviation rule`, choose: **Type:**  `Team bypass (skip a branch for matching cases)` ## 2\. Starting point of the condition  As the target we use:  `bestellanforderung` The condition is to be evaluated on an attribute of this object. In our example, that is: `anforderer` This lets us make the process behavior directly dependent on a business data attribute. This is a key difference from a purely random deviation: It is not just any case that bypasses the approval; rather, the behavior is deliberately linked to certain requesters. ## 3\. Defining the branch to be skipped As the `Branch owner` we choose: `freigabe_a` `freigabe_a` is part of the branch with the tag: `DUAL` The engine uses this branch owner to determine the associated branch. When the bypass rule takes effect, the slots of this branch are skipped for the case in question. As a result, the intended approval steps disappear from the process execution in the corresponding case. ## 4\. Setting the condition on the requester Configure the condition: **Column:**  `anforderer` **Operator:**  `in` **Value:**  `Kaya, Braun` With `in`, the Smart Data Forge interprets the comma-separated values as a list. The rule therefore applies exclusively to purchase requisitions whose `anforderer` is either `Kaya` or `Braun`. ## 5\. Configuring the probability Set: **Probability (%):** `80` This corresponds to the configuration of the full P2P demo. There, the `Team Bypass` for `Kaya` and `Braun` is likewise set with a probability of 80%. The interpretation of these 80% is important. They do **not** mean that 80% of all 500 cases become maverick-buying cases. The rule can only take effect when several conditions come together: - the requester is `Kaya` or `Braun`, - the original XOR decision selected `DUAL`, - and the 80% probability of the `Team bypass` then applies. The engine explicitly checks whether the case would originally have taken the branch of the selected branch owner before the bypass is applied. This produces a considerably more meaningful data picture than a blanket 80% deviation across the entire data set. ## Do not use a fixed quota For this use case, we deliberately adopt the logic of the existing P2P demo: **80% probability, no fixed** `**exactly N %**` **quota.** This way, a probabilistic decision is made for each relevant case. Unlike later use cases such as rework or wrong order, we do not want to force an exactly specified number of cases to arise here. This also fits the scenario in business terms: the behavior of certain requesters should have an increased probability, not an artificially exact predefined number of cases. ## 6\. Flagging the deviation Set as the `Tag`: `FREIGABE_UMGANGEN_TROTZ_SCHWELLWERT` This tag, too, is adopted from the existing P2P demo. The tutorial config is prepared so that such tags can be written into: `bestellung.abweichung` . ## The finished rule The configuration can be read, in business terms, as follows: > If the `anforderer` of the purchase requisition is `Kaya` or `Braun` and the case would actually run via the `DUAL` approval path, this approval branch is bypassed with a probability of 80%. Technically, this yields: **Target:** `bestellanforderung`  **Branch owner:** `freigabe_a`  **Condition:** `anforderer IN (Kaya, Braun)`  **Probability:** `80 %`  **Tag:** `FREIGABE_UMGANGEN_TROTZ_SCHWELLWERT` ## What changes in the data set as a result? Before the rule, we had two regular variants: **DUAL** `Bestellanforderung → Freigaben → Bestellung` **DIRECT** `Bestellanforderung → Bestellung` After the rule, a third business-relevant pattern is added: **Maverick Buying** Based on the original process decision, the case would have been a `DUAL` case, but the intended approvals are not executed due to the additional bypass rule. At first glance, the resulting activity path can therefore look similar to a regular `DIRECT` case. However, the **reason for this path is a different one**. This is exactly why, alongside the process pattern, we also model the cause via `anforderer` and the deviation tag. ## What should I later see in Noreja? In the later analysis, it should be possible to identify cases in which: - a `bestellanforderung` is present, - a `bestellung` subsequently comes into being, - the expected approval activities are missing, - and this behavior is disproportionately associated with the requesters `Kaya` and `Braun`. An interesting analysis question is therefore not only: **"How many orders have no approval?"** but: **"Which causes / attributes explain why certain orders do not go through the intended approval process?"** This turns a simple process variant into a causally interpretable use case. ## Common mistakes / things to watch out for **Do not equate** `**DIRECT**` **and maverick buying.**  A regular `DIRECT` case is part of the intended process model. The maverick-buying case only arises through the additional `Team bypass`. **Do not use** `**Overjump**` **for a single approval slot.**  Our approval process consists of a branch. That is why we use `Team bypass`, so that the complete relevant branch is bypassed. **Do not interpret the 80% as a share of all cases.**  The probability applies only to matching `Kaya` / `Braun` cases that would originally have taken the `DUAL` branch. ## Result Our previously clean base model now contains the first deliberately generated process deviation. In doing so, we did not simply remove approvals at random, but created a relationship: `anforderer` → increased probability of an approval bypass → altered process variant → recognizable deviation in the data. With this, we have applied the central principle of the Smart Data Forge in practice for the first time: **A business hypothesis becomes a controlled, deliberately generated causal data pattern.** ## Next step Next, we look at a different type of cause. This time we do not remove a process step, but change its **duration**: **How does a poorly performing supplier affect the cycle time of the procurement process?** For this, we configure `Globex SE` as a conspicuous supplier and use `Conditional Rules` for the first time. **Next:** [**Tutorial P2P Error Pattern Poor Delivery Performance**](https://docs.noreja.com/en/article/p2p-tutorial-error-patterns-indicating-poor-delivery-performance)