Skip to main content

​
Apps

​
Access & Visibility

  • App Access Required: Apps are only visible to users who have access to records within that app.
  • Check Access Policy: Ensure the user has an Access Policy configured for the app.
  • No Access = No Visibility: If a user lacks proper access, the app won’t appear in their app list.
  • Role-Based Access: Features are only visible to users with appropriate role permissions.
  • Organization Admin Setup: Roles and permissions are configured by Organization Admins.
  • Permission Check: Verify the user has a role that includes the necessary permissions.

​
Dashboards & Updates

  • Home Page Dashboards: These are user-specific and don’t sync across users.
  • Shared Dashboard Limitation: When you share a dashboard, it creates a copy for the other user.
  • App Dashboards: Use App Dashboards for a single source of truth that updates for all users.

​
Relationships & Connections

  • Record Access Required: Relationships are only visible to users with access to the related records.
  • Permission Check: Verify the user has access to both the source and target records.
  • Hidden Relationships: If access is missing, relationships won’t be visible even if they exist.

​
Deleting Apps

Deleting an app is permanent. The app and all of its data cannot be recovered after deletion.
  1. Open the app you want to delete.
  2. In the left sidebar, locate the Admin Settings section.
  3. Click the More icon (three dots) next to Admin Settings.
  4. Select Delete [App Name] from the dropdown.
  5. Confirm the deletion when prompted.

​
Managing Records

There is no bulk delete action for records inside an App or Element. Records must be deleted one at a time from the record’s detail page. See Delete a Record for the steps.If you need to remove every record in an App, deleting the App itself permanently removes the App and all of its records. See How do I delete an app? above.
Records cannot be moved between objects, whether App to App, App to Element, or Element to Element. Each object has its own record details layout, field configuration, and relationships, so a record from one object is not compatible with the structure of another.To relocate data, recreate the record in the target object. You can do this manually, through Bulk Import, or with a Create Record automation that reads from the source object and writes into the destination.
On a record, each value in a multi-select field appears as its own badge with the option’s configured icon and label, in the order the values were saved. This lets you read the full set at a glance instead of seeing only the first value with a “+N” counter.Long lists stay compact: the field collapses to about two lines and shows an inline Show more / Show less control that reports how many values are hidden. This is display only — it does not change how you edit the field or which values are stored, and it applies to the record view.
On the record details page, long titles use the full header width and wrap up to three lines instead of truncating to one line with an ellipsis. Status appears next to the record ID so it does not take width away from the title.To edit the title, click it to enter edit mode, then confirm or cancel. Clicking away discards the draft instead of saving it. Confirming without changing the text does not create a record update. This behavior applies to the record details header only — list columns, board cards, and mobile layouts are unchanged. See Edit a Record Title for the steps.

​
Elements

Elements and Tables organize and act on data for different purposes. Here are some examples of when you would use each:Use Elements when:
  • You’re managing a vendor master list — each vendor has a unique ID, you need to track changes, relate vendors to purchase orders, and control who can edit vendor records.
  • You’re building a customer database — you need validated fields (email format, required phone number), relationships to orders/tickets, and audit trails.
  • You’re storing configuration data like approval thresholds or SLA definitions that workflows reference during execution.
Use Tables when:
  • You need a cross-functional dashboard — joining customer data (from an Element) with order data (from Snowflake) and support tickets (from Tasks) into a single analytical view.
  • You want to trigger automations based on data conditions — Tables feed Data Mines, which monitor for things like “claims over $10,000” or “inventory below reorder threshold” and fire workflows.
  • You’re exposing data to BI tools — Tables can create Snowflake Views that Power BI or Tableau can query directly.
  • Your data doesn’t have a natural unique identifier or you’re working with aggregated/analytical datasets.
It depends on how the Element is connected to Snowflake.CloudLink-backed Element: If the Snowflake table that powers the Element is updated from an external source on a schedule — for example a monthly load — then yes. After that update, the Element shows whatever is in Snowflake. Records you created in Elementum that are not in the source load will no longer appear.Element populated by a Data Mine: If the Element is not CloudLink-backed, and a Data Mine processes matching warehouse rows into the Element (typically through a Create Record automation), then no. Records you create manually in that Element stay in the Element. The next Data Mine run does not remove them.Read/write access: A CloudLink-backed Element can be set up with read/write access. In that case, no — records you create or edit in Elementum are written back to the Snowflake table, so the next refresh does not remove them.If you are not sure which pattern your Element uses, check whether it is mapped to a warehouse table through a CloudLink, or whether it stores its own records and is filled by a Data Mine and automations.

​
Need More Help?

If you can’t find the answer you’re looking for, check out our support documentation or contact our team for assistance.