Skip to main content

Events

Each event captures a single action or system occurrence at a point in time and becomes the source for adoption, operational and financial metrics.

Cloudaware normalizes events from the application backend, jobs, and integrated modules into a consistent schema before loading them into Salesforce CRM Analytics.

Event Types​

Typical event types include:

  • Module usage
  • Pipelines & jobs
    • Ingestion job started/completed/failed.
    • Dataset refresh started/completed/failed.
    • Export job started/completed/failed (for example, CSV, S3, warehouse).
  • System & governance
    • RBAC or role assignments changed.
    • Tenant configuration changes (for example, module enabled/disabled).
    • Integration or connector enabled/disabled.

The exact set of events in your org depends on which modules and integrations are turned on.

Event Schema​

At a high level, every event carries:

  • Event ID – a stable unique identifier for the event.
  • Timestamp – when the event occurred (UTC).
  • Event type – a normalized type code (for example, user.login, dashboard.view, policy.evaluate, job.failed).
  • Actor
    • actor_type – user, system, or integration.
    • actor_id – reference to the user, API client, or system identity.
  • Object
    • object_type – what the event is about (for example, dashboard, policy, module, CI).
    • object_id – identifier of the affected record or resource, if applicable.
  • Context
  • Metadata / payload
    • Additional attributes specific to the event (for example, status, duration, counts, error messages).

Events are modeled to be self‑contained: each record should have enough information to be useful on its own, while still being linkable to CMDB and other modules.

Normalization & Enrichment​

Before events are loaded into CRM Analytics:

  • Redundant or noisy raw events are deduplicated.
  • Event types from different sources are mapped to a canonical taxonomy (for example, many different “view” actions become dashboard.view).
  • IDs are resolved to CMDB records where possible so events can be sliced by CMDB attributes.
  • Tenant, module, and ownership information is added to support RBAC‑aware analytics.

See Ingestion – Event Sources for details on where events come from and how they are collected.

Relationship to Metrics​

Most metrics described in Metrics are computed from these normalized events:

  • DAU/WAU/MAU are derived from distinct users with qualifying user.* events.
  • Feature adoption is derived from specific object.* or module.* events.
  • Time‑to‑detect and time‑to‑recover are computed by correlating incident or policy events over time.

When designing new KPIs, start by defining the underlying event types and fields you will need.