Informing Teams

Keeping teams informed is a crucial aspect of your organization that ensures your team remains unified, well-informed about project developments, and feels like a cohesive entity with a shared agenda. There are countless methods, tools, and applications to facilitate this.

Within the GUBUS paradigm, maintaining a shared agenda involves having a common group where team updates occur, including:

• Accounted orders
• Production events
• Delivery events
• Order closures
• Other relevant project operations
• Spaces where teammates can converse

Thus, we find that simply having a group in a messenger with a bot posting all updates is the perfect, lightweight, quick-to-develop, low-cost, and intuitive solution for potentially complex and over-engineered problems.

Informing About Single Items

The single item inform pattern is incredibly useful for tracking crucial item states - orders, bookings, events, closures - essentially, the core elements around which the GUBUS item-mode is built. If many fields of a critical object item need to be exposed to the entire team, you can configure the GUBUSsingle inform pattern!

For item inform cases, GUBUS has developed a two-fold pattern, which consists of:

• Main info pattern - which fields should be exposed and in what form
• Footer/header pattern for items at a relevant stage

For reasons of performance and usability, we have currently opted to hardcode the main info pattern. Therefore, you should request its instantiation from your personal developer. However, we have made the footer/header pattern and stages assignment accessible, as illustrated below:

As evident from the above image, GUBUS has developed an exceptionally flexible item model that can be easily configured on-the-go, determining which stage and item state should be captured for exposure.

Sequential resolution implies that all read properties are checked sequentially. Once a match is found,GUBUS halts the evaluation of single info preparation and outputs the found headers and footers.

Informing About Multiple Items

Similar to the single-inform pattern being tied to the main item state, the next GUBUS info pattern - couple_info_preparation - is developed to group information about multiple processed items.

The couple inform pattern has two implementations:

• Multiple items resolved in a workfeed
• Multiple items read from a multipanel

Informing About Multiple Workfeeds

When exposing a workfeed event, we typically aim to inform that items have been resolved here and moved to another stage. This event is notably succinct.

To configure it, simply populate the couple_info_preparation rule with relevant stages and workfeeds information as shown below:

As you can observe, this rule is also sequentially resolved. For instance, if the case with white-label item status in row 137 matches the items status, execution will halt. Otherwise, execution will proceed to the next row, 138.

Informing About Multiple Multipanels

When multiple items are entered through a multipanel, the exposure requirements differ from those of workfeeds. Typically, we aim to ascertain the specific items and their respective quantities that were read, necessitating the configuration of additional fields and operations.

By default, a GUBUS-box is configured to extract items read by two specific fields. The rule under these fields is configured in columns:

• operation_name
• count_label

If you require a different message pattern, it can be customized with ease. Simply request this from your dedicated GUBUS developer.

Personal Notifications

While GUBUS does offer out-of-the-box personal notifications, we seldom see a substantial need for it. The majority of the information processed in GUBUS should be, and indeed is, exposed to a common area, facilitated by the team inform GUBUS module.

The only scenario where personal notifications from GUBUS would be necessary is to inform a user about an error they have made. This functionality is already covered by default in a GUBUS-box.

When an error is detected (by the input-validator module), GUBUS halts further execution, returns an error message to the sheet where the incorrect input was attempted, and sends a validation error message to the user personally.

For more information about GUBUS's layered validation functionality, you can read here