The manner in which alerts and notifications are handled was also changed in the Paper Plane release. It's similar to business validation, where we have standard rules for things like quoting, rebates, and sales compensation. With the Paper Plane release, we've added more business validation to highlight specific aspects in a quote, or bring attention to certain conditions. Sometimes, as a user you want to avoid submitting something if certain conditions aren't met. Let's go ahead and look at a few examples.

Open

Open

Alerts

Consider for instance that you're a salesperson and you're working on a fast quote for a customer. You've already selected the customer and now you're adding a few products to the quote and potentially lower the price for others as per your negotiation with the client.

Now you can go ahead and lower the price and recalculate it with little hassle.

You'll notice a few things here. First, we had some inconsistencies with the alert types that were being thrown from the logic. Some were showing up as green messages indicating successful calculation, while others were showing up as green messages but with errors.

Notifications

A significant change that has been made was to ensure that we have a consistent coloring scheme based on the criticality and severity of the error. This means that whenever an alert is thrown, you'll see a text message with the proper title and message that you've defined as part of the validation. For instance, in our case, the message reads "Price is below floor price", and it's properly formatted. We've also added more spacing to make it easier to read if there are multiple alerts. In this case, we are having the same issue with both items so the message will appear only once. Since it's a critical alert, the text won't disappear until you close it. Additionally, these alerts are relayed to the notification center.

Issue Counter and Color Coding

You will notice a counter next to the custom header that will catch your attention. The alert is triggered from the line item, as we're in the items tab. As you scroll through the table, you'll notice that the problematic line item is marked with a red section in the top left corner, so you won't lose track of it. This feature solves the horizontal problem when you have many columns and are losing track.

Moreover, there's a filtering capability that works well when you have many line items to manage. You can filter out all the line items with this critical alert, making it easier for you to focus on the ones with issues. You can then scroll through and see which alerts have been thrown and resolve them accordingly.

If you have more alerts thrown with different categories, they'll be color coded (for warnings it is yellow, critical ones are in red) and displayed next to each other so you can filter them out as you go. This is a simple validation. For this example, we'll just go ahead and put the price above the lower price.

We'll recalculate, and once calculated successfully, the counter is gone. At this point you can be sure everything is alright so you can submit it.

Integration with Agreements and Promotions

The same concept applies if you were to throw an exception from the header logic.

Let’s take a look at how this works in contracts. For this example we will select an agreement that does not entirely comply with the rules. If we recalculate, we'll see a message that says every contract type should have a product selected.

Even if you close this message, it's still possible to access it here.

So we can go ahead and select the product, recalculate, and that will resolve the error.

Renaming the Quote

If we go back to Quotes and recalculate, you'll notice that the message used to be hard-coded to say "Quote calculated successfully."

However, if you're a customer who renames the modules, you can now override these messages to make them consistent with what you're calling your module. So if you call them deals, for example, you can rename this message to say "Deal calculated successfully" or with errors or alerts depending on the type of message that's being thrown. The feature is using existing API functions. So if these alerts already exist in the logic, this behavior will be adopted, and these banners will be shown.