Core Concepts

The following concepts appear frequently throughout Sales Engine.
They are critical for understanding how the platform behaves and why some options are unavailable until others are complete.

Organisations

Represents the customer company.

Teams, users and API accounts may all be attached to an organisation, allowing their administration.

Teams

A group of users or API accounts which have some common scope of access.

Customers can be a member of one or multiple teams and all members of a team will have any access granted to that team, and inherent any constraints placed upon it.

Example:

• Team 1 — Coastal Monitoring Team
• Team 2 — Defence Applications Team

Users

Individual people that can log into the sales engine, your customers.
Users may belong to an organisation and optionally be part of one or more teams, depending upon how their account was created.

Users will only ever see orders, billing accounts, campaigns, etc that they have permission to, either directly or through a team that they are a member of.

Permissions

Permissions are a link from a user, API account or team, that grants access to some resource.
The access of any user is determined by the sum of all permissions they have

i.e. if a user has permission to a dataset through two different teams, and one has download permission while the other does not, the user will be able to download resources from that dataset.

The types of permission that can be granted depend on the product type of the target, and will be elaborated on elsewhere.

Constraints

Additionally, while permissions link to specific resources, constraints can control access to behaviours, such as maximum order size, approval requirements and similar.
Users, teams and their parent organisations may have rules applied to them to “constrain” this behavior.

Constraints can be applied at the organisation, team or individual user level, with lower levels overriding higher ones.
For example; you can set a default of no-one in an organisation can place orders, but authorize a team within the organisation to be able to place orders.

The following constraint features are accessible to organisation managers and platform administrators:

• Preventing orders
• Restricting the maximum size of an order
• Restricting which suppliers may be ordered from (if multiple suppliers are available on the platform)
• Restricting ordering to a set of approved licenses
• Requiring ordering approval from a set user or team
• Requiring ordered data be owned by a set user or team
• Automatically adding all ordered data to a set collection (if available in platform)

In addition the following constraint options are only available to platform administrators:

• Granting access to “restricted” suppliers
• Assigning a payment group (if multiple payment matrices are configured)
• Assigning special purpose roles (for modifying pricing, license availability, etc)
• Adding custom attributes (which may affect other restrictions based on platform configuration)

If a user cannot see tasking opportunities or archive results in the browser, it is most likely they have been constrained to remove those options.

In particular, if you platform has an Restricted Party Screening (RPS) process configured, or no default pricing matrix, no results will be visible to the user until they have been screened and/or assigned a pricing group respectively.

Billing

There are several ways a customer can pay:

Payment accounts can be created with or without a payment method attached, but may have at most one method.
A credit balance can be added to any payment account by an administrator, even without a payment method.
If the account has insufficient credit balance to satisfy an order, it will fall back to the underlying payment method for the difference, unless there is none, which will result in a payment failure message.

A customer can have multiple payment accounts, however when ordering, only one payment account can be selected for a given order.

Orders

Orders represent a financial transaction in the platform, and a request for purchase (even if the amount is zero).
Customer requests will create an order representing the transaction and request, storing the financial information.

The order will then contain some combination of tasking campaigns and archive datasets representing the items ordered.

If creating a custom order for a customer, additional line item details can be added to these items, or as independent records, as a way of tracking bespoke elements of the request and service to be rendered.

Campaigns

A campaign is how a tasking request is executed in the scheduling pipeline.

A Custom Order can contain zero or more campaigns.

Each campaign requires:

• An Area of Interest (AOI)
• Time window (start and end of period)
• Capture parameters (off nadir, azimuth, supplier and satellite constraints, etc)
• Pricing information (product level, license, priority, etc)

Campaigns are what schedulers work with daily, and this scheduling information can be presented to users to keep them notified of upcoming captures and the status of their order (depending on platform configuration).

As data for a campaign is fulfilled, datasets will be created to contain the delivered data, which will then be accessible as their own entity, as well as a child of the campaign and its parent order.

Datasets

A dataset represents a measurement set of delivered data which is continuous in space and time.

Datasets are created for archive orders to represent the data to be delivered, and also for tasking campaigns to represent the portion of capture being delivered to the customer.

Datasets are composed of:

• An Area of Interest (AOI)
• The datetime the data corresponds to
• Identifiers for the supplier and source scene/capture it is created from
• Product information (processing level, license, etc)
• An optional expiry (if platform is configured for expiring deliveries)
• A list of file resources making up the data, which include
  • The resource’s name,
  • File size
  • Format and checksum
  • A structured list of roles this resource fulfills

Statuses

The Geostack platform has a number of status codes, which share their definition between orders, campaigns and datasets.

They broadly fall into the following categories

Preparing & Pending statuses

These statuses exist for the purpose of preparing custom orders, or those requiring further action by a (e.g. approval by a manager or screening by an administrator).

Processing statuses

These statuses exist for the purpose of communicating that the order is in progress and will be fulfilled.

Terminal statuses

There are final statuses for an order and under normal circumstances, an order will not leave one of these statuses.

Notifications

Sales Engine can notify users of a number of different changes within the platform.
Which events are notified, how, and the content of which can be customised to suit your platform configuration and branding.

The most common notifications are for:

• Account events
  • signup,
  • password reset,
  • added to a team,
  • granted access to data
  • request for access to data
• Ordering events
  • receipts
  • ordering approval requests
  • custom order proposals
  • order/campaign/dataset update and completion
• Internal/operational events
  • order lodgement
  • scheduling request
  • order process failures/errors
  • customer proposal responses

Notifications can be sent by multiple mediums based on need for the particular message type, including:

• email
• webhooks
• in platform notifications (on the dashboard)
• pubsub messages (SNS, SQS, RabbitMQ, Kafka, etc)