FAQ

This article covers common questions when using Omnata.

Inbound storage location configuration

Granting inbound table access to other roles

If you would like to grant access to this table to other roles, you grant the OMNATA_ADMINISTRATOR role to the other role. Run the command:

grant application role OMNATA_SYNC_ENGINE.OMNATA_ADMINISTRATOR to role MY_OTHER_ROLE

Modifying the inbound storage location to a database and schema outside of the app

This is required if you would like to enable Snowflake features that are not available in app-databases; such as Hybrid tables, changing tracking and others.

1. In the sync's Controls tab, expand Storage Location and choose Modify:

   
2. Customize the location, and enter a database and schemas that you own (outside of the app database):

1. Grant the following privileges (substituting for the actual database/schemas you choose):

grant usage on database MY_DB to application OMNATA_SYNC_ENGINE;
grant usage on schema MY_DB.INBOUND_RAW to application OMNATA_SYNC_ENGINE;
grant usage on schema MY_DB.INBOUND_NORMALIZED to application OMNATA_SYNC_ENGINE;
grant create view on schema MY_DB.INBOUND_NORMALIZED to application OMNATA_SYNC_ENGINE;
grant create table on schema MY_DB.INBOUND_RAW to application OMNATA_SYNC_ENGINE;

1. After doing this, you should clear the sync state in order to have the streams start from the beginning again. Go to Controls tab > Sync State expander.

2. After the next sync run, you should be able to take ownership of the tables that the sync engine creates and enable change tracking. Ensure that you grant all privileges on each table back to the application:

grant all privileges on table MY_DB.INBOUND_RAW."main_Contacts" to application OMNATA_SYNC_ENGINE;

Outbound syncs show the source table being empty

You may have a row access policy in place. If so, your policy will need to return true when CURRENT_ROLE() = 'OMNATA_SYNC_ENGINE'

Record history retention

Omnata keeps a full record history of sync activity inside the app's internal tables. This is to enable record-level troubleshooting for syncs and runs. For large sync payloads, this duplicate copy of records can create a storage overhead and can increase sync post-processing times.

You can customize the retention period in days under Settings > Data Management > Record History Retention. In the case of long running sync runs, setting this parameter to Zero can cut overall sync run times by ~30%, however, you will only be able to view aggregated historical metrics for sync runs going forward.

Sync run timeout

If a sync or an object in a sync fails due to timeout, it can be the result of two possible timeout settings.

1. The timeout parameter on the individual sync. This is configured in the Deployment step of the sync creation wizard after setting the sync schedule; the default is 240min.

2. The STATEMENT_TIMEOUT_IN_SECONDS setting for the Snowflake account. This places an upper limit on the time a query can run for. The default is 2-days, but if this has been lowered, it will override the setting in the Omnata Sync application.