Skip to main content
Honeydew can publish a domain to Sigma as a data model, so you can build workbooks on top of the Honeydew semantic layer. The data model is backed by a Honeydew connection in Sigma.
Sigma support is in Beta.
Publishing a data model requires a one-time API access setup — see Sigma API Integration.

​
Publishing a domain as a data model

From the Honeydew UI, select Publish data model and provide:
  1. Domain — the domain to publish as the data model.
  2. Workspace — the Sigma workspace to place the data model in.
  3. Connection — the Honeydew connection in Sigma (only selectable when more than one exists).
  4. Folder — the folder for the data model.
  5. Data model name — type a name to create a new data model, or select an existing one in the folder to update. See Updating an existing data model.
  6. Version tags — optional Sigma version tags to apply to the published version. See Version tags.
Honeydew creates (or updates) the Sigma data model backed by the Honeydew connection. Along with the fields, Honeydew syncs the following metadata:
  • Field type — every attribute is synced as a dimension, and every metric as a measure.
  • Folders — dimensions are grouped into folders in Sigma.
  • Field display names. When no display name is set, Honeydew creates an automatic user friendly name.
  • Field descriptions.
  • Field format string (see Sigma-specific Metadata).
You can now build workbooks on top of the published data model, using the Sigma user interface.

​
Updating an existing data model

The Data model name field is where you choose between creating and updating:
  • Typing a new name creates a new data model (marked New).
  • Selecting an existing model in the folder updates it (marked Override). Honeydew shows the version tags currently applied to that model, and asks you to confirm before overriding it.
Each publish adds a new version to the data model, keeping earlier versions in Sigma’s version history.

​
Version tags

Version tags let you pin a published version so workbook builders can consume a specific version instead of the latest. Select one or more of your organization’s Sigma version tags to apply to the version being published. A version tag moves to the latest published version each time you apply it, so a tag such as Production always points to the most recently blessed version.
Tags must already exist in Sigma before you can apply them. Applying a tag is best-effort: if the model publishes but tagging fails, Honeydew reports that tagging failed and still keeps the published version.

​
Sigma-specific Metadata

You can control how a field is formatted in Sigma by adding a formatString to the field’s sigma metadata section. The value is a D3 format string, which Sigma applies natively (for example $,.2f for currency or ,.0f for a whole number). See Sigma’s format columns and metrics documentation.
Only number and date/time fields can be formatted. A formatString on a string or boolean field is ignored.

​
Metrics and Calculated Attributes

For metrics and calculated attributes, add the metadata to the field’s own YAML file: 
...
metadata:
  - name: sigma
    metadata:
      - name: formatString
        value: '$,.2f'
For dataset attributes, add the metadata under the attribute entry in the dataset’s YAML file: 
...
attributes:
  ...
  - column: <src column name>
    name: <attribute name>
    ...
    metadata:
      - name: sigma
        metadata:
          - name: formatString
            value: ',.0f'

​
Refreshing a data model

Changes in calculations reflect automatically and immediately in Sigma.
Connect Sigma to a development branch so logic changes in Honeydew reflect immediately in your workbook — a quick experimentation workflow on Honeydew semantics.
Any other change will not reflect in Sigma until publishing the data model again. In particular, the following changes require publishing again:
  1. Changing metadata: descriptions and display names
  2. Adding new attributes or metrics
  3. Renaming or removing attributes or metrics
  4. Changing the entities or fields that participate in a domain