Orbit MissionControl Orbit Hub Orbit Connect Orbit Cockpit
βœ… 🚫 🚫 🚫

<aside> πŸ“¦ As a starting point we recommend first understanding the concept of TransportShapes and TransportComposers before diving into this article.

</aside>

Overview

Orbit Decode revolutionises how unstructured order emails are handled, converting them into actionable Transport (Order, Shipment and/or Tour) objects within the Orbit platform. Decode fundamentally simplifies the handling of order emails saving valuable time in daily operaitons. Through automation and AI, Decode frees users from tedious manual tasks, paving the way for more efficient and error-free data processing.

This document aims to demystify Decode, outlining its features, workflows, and the synergy between its components.

Key Highlights

Decode Process

As a transformative feature designed to redefine the workflows of Orbit users, understanding the individual components that constitute the decoding process is essential. Generally, it's practical to distinguish three distinct stages within each Decode process: Getting Data into the system, processing of the data in the background, and the final review of decoded data inside an automatically filled-out TransportComposer.

As highlighted earlier, we advise first understanding the TransportShape and TransportComposer concept. Nevertheless, here's a brief refresher on the crucial elements that are important for understanding the Decode flow:

  1. TransportComposers: Customisable forms allowing users to create Offers, Orders, Shipments, and/or Tours, all within one go.
    1. TransportDrafts: Preliminary versions of TransportComposer forms, automatically saved as users make edits.
  2. TransportShapes: Configuration objects for full customisation of TransportComposers.

1. Data Inflow

The first step of each Decode Job is all about getting relevant data into the system. Decode is optimised on the principle that each email message, including its attachments, should encapsulate all relevant information about a transport. This means that, whatever entry point into Decode you choose, try to limit every job to one isolated transportation context. Or in other words: Ensure that each transport is contained within a single Decode Job, avoiding fragmentation across multiple jobs (1 Decode Job = 1 Email = 1 Transport).

<aside> πŸ’‘ Currently, our system limits attachment processing to a maximum of 30 attachments per email. This includes images embedded within the email body or footer, which may not be immediately apparent as attachments.

</aside>

Currently there are two distinct entry points for initialising Decode jobs.

Entry point: Magic Inboxes

A MagicInbox is an Orbit-generated email address that automatically creates a Decode Job for every incoming email. A Magic Inbox is always linked to a TransportShape and may include Presets and MagicFields for fields that are visible as per the TransportShape configuration and may override Decode’s data output. To set up this flow, follow these steps: