Intro
Domo Everywhere allows you to quickly and easily replicate Pages and Cards from the Publisher instance and share them with customers in a dedicated Subscriber instance. Control all the content by filtering to the appropriate data for each Subscriber before it is published. Manage all of your Publish Jobs, content, filters and Subscribers all in one convenient, central location within the Admin Settings.
You can access Domo Everywhere if you have an "Admin" default security role or a custom role with the "Create Publications", "Manage All Company Settings", "Manage DataSet", and "Edit Cards" grants enabled. For more information about default security roles, see Default Security Role Reference. For more information about custom roles, see Managing Custom Roles.
Here are some terms you should know before using Domo Everywhere to publish data to an edit experience:
- Publisher - The instance that pushes the data out to the Subscribers. Domo Everywhere always lives in the Publisher instance.
- Subscriber - The instance that receives data from the Publisher.
- Job - Configure the Cards, DataSets, and filters that will be published as well as select which Subscribers should receive the content. You can create multiple Jobs.
- Data Permissions - Custom filters you can set for each Subscriber to control what rows of data they are allowed to see.
Getting this feature
If you are interested in using this feature, please contact your Customer Success Manager (CSM).
Note: This feature is available on demand and paid.
To request this feature be enabled,
-
Reach out to your Domo Customer Success Manager, Technical Consultant, or AE.
-
If you do not have contact information for your CSM, TC, or AE, contact Technical Support by using /Support in Buzz or by email at support@domo.com
Depending on the feature, you may be required to complete training before you can use the feature.
Requesting a Subscriber Instance
This is different than Publish V1. The request should be sent to Sales Ops. They will validate that the customer has a contract for additional instances. The standard naming convention is publisher-subscriber.domo.com.
Video - Creating a Publish Job
Creating a Publication
- Navigate to More > Admin > Feature settings > Publish.
- Choose Publications.
- Choose New Publication.
- Name the Publication.
This should be a name that will identify the job.
The description can be used to document the content that is being published and the recipients of the content/data that is being published.
Click Next.
- Add New Subscriber.
To add a Subscriber, it is necessary to know the URL of the Subscriber domain. The format for this domain is subscriber.domo.com
Subscribers that have been added to other Jobs will appear in the list as options to select.
Click Next. - Choose the Page or Pages that you want to Publish.
Note: The Pages that are chosen must be shared with the user configuring the Job.
Important: When you add a Parent Page to a Publish Job it automatically adds all of the Subpages of that Page.
Click Next.
- Review DataSets that power the Dashboard.
The toolkit will automatically select DataSets that are required to power the Cards.
Additional DataSets can be added if desired.
Click Next.
- Set Data Permissions.
If all rows for a DataSet are to be shared with the Subscriber, then select the Include in publication box. If a filtered version of the data should be shared, select the Add Permission button. This will bring up filtering options to filter the data.
Important: One policy must be chosen for each DataSet whether that is All Rows or a subset of rows by utilizing filters.
Click Next.
- Final Review and Save.
Review the final information before saving to confirm that the number of Pages, Cards, and DataSets are as expected.
Click Save.
Note: This will make the Publication available for subscription in Subscriber instances. Subscribers will still need to accept the invitation before any content appears.
Video - Subscribing to a Publication
Subscribing to a Publication
- Navigate to More > Admin > Feature settings > Publish of the Subscriber instance.
- Choose Subscriptions.
- Choose Invitations.
- Review Invitations and click the Subscribe button.
- Accept invitation.
Once accepted, the Publish Toolkit will immediately start to populated the Pages, Cards, and DataSets that are included in the Publication.
Refreshing a Publication
- Navigate to More > Admin > Feature settings > Publish.
- Choose Publications.
- Find the Publication that should be refreshed, hover over the Publication, click the wrench icon on the right-hand side, and select Refresh.
Note: If you make changes to a Dashboard or a Card in a Dahsboard, you will need to refresh the Publication in order for it to show in the Subscriber instance.
Important: Do not modify the source Pages while the job is being refreshed. This causes the layout of the Page to change and it corrupts the layout of Cards in the Subscriber instance.
Deleting a Publication
- Navigate to More > Admin > Feature settings > Publish.
- Choose Publications.
- Find the Publication that should be deleted, hover over the Publication, click the wrench icon on the right-hand side, and select Delete.
Note: This will immediately start the process of removing the Pages, Cards, and DataSets that have been subscribed to from all Subscribers.
Unsubscribe from a Publication
- Navigate to More > Admin > Feature settings > Publish of the Subscriber instance.
- Choose Subscriptions.
- Choose Subscriptions.
- Find the Subscription to unsubscribe from, hover over the Subscription, click the wrench icon on the right-hand side, and select Delete.
Note: This will immediately start the process of removing the Pages, Cards, and DataSets that have been subscribed to as part of the Publication.
Details on DataSet PDP Policies
If the same DataSet is shared in two Publications to the same Subscriber instance, the PDP policies of the more recently saved Publication will be used for data permissions.
In the event that a Publish user wants to share the same DataSet to the same Subscribers twice with different permissions, they will need to duplicate the DataSet in the Publisher instance.
Removing Pages from a Publish Job without impacting the underlying published DataSets
When editing an existing Publish Job, it’s important to note that if you remove a Page from the Publish Job, the underlying DataSets powering the Page will also automatically be removed from the Publish Job when the Page is removed. If any of those DataSets are being used in the Subscriber instance to power any custom-built Cards within the Subscriber instance, those Cards will also be automatically deleted from the Subscriber instance when the DataSet is removed.
If you wish to remove a Page from the Publish Job, but want to preserve the underlying DataSets that originally powered the Page you are removing within the Publish Job, ensure that within the same Publish Job edit session, that you first add a new Page containing Cards that are powered by all of those specific DataSets before removing the original Page and saving the Publish Job, or alternatively, ensure that all of the DataSets are reselected in the DataSet section of the Publish Job before you save the Publish Job.
Another option would be to build one Page in the Publisher instance that contains a simple table Card for each of the DataSets that are going to be part of that specific Publish Job. When you create your Publish Job, along with the other Pages you are wanting to Publish, include this Page. Once this Page has been added to the Publish Job, it should never be removed from the Publish Job. By doing this, you can then add and remove any of your other Domo Pages from the Publish Job without affecting the underlying DataSets. Just remember to keep the Page containing all of the table Cards up to date with all of the DataSets that you want to remain in the Publish Job as to not affect any custom content that has been specifically built in the subscriber instance.
Publishing the same DataSet from the Publisher instance to the Subscriber instance via two Publish Jobs
Each Publish Job will push all of the DataSets that exist within each Publish Job to the Subscriber instance, even if the DataSet already exists in the Subscriber instance due to another Publish Job which is already publishing that DataSet to the same Subscriber instance.
For example, if a Subscriber instance has subscribed to two Publish Jobs from the main Publisher instance, and both of the Publish Jobs contain the same DataSet (or DataSets), you will see two copies of the DataSets in the Subscriber instance with the exact same name. While each DataSet will have the exact same name, they will have different Dataset_Id values and each copy of the DataSet will relate to a specific Publish Job. This is because currently, the Subscriber instance does not know that the same DataSet has been Published twice from the Publisher instance via separate Publish Jobs. To avoid confusion of which DataSet relates to which Publish Job in the Subscriber instance, consider only Publishing the DataSet once, within only one Publish Job, to the Subscriber instance if possible.
FAQs
Can Dataset Views be published across accounts?
Yes, but remember to follow the best practices around PDP policies as explained in Publishing DataSet Views.
Can dynamic text or data variables be used in publications?
Soon. That is being worked on now. Support in Domo Everywhere publications is expected later this year.
Do Alerts get applied in Subscriber instances as part of Publish?
Alerts are not copied by Publish across accounts. Subscribers can still create Card Alerts on their side that are triggered by numerical thresholds (as shown on the right). DataSet Alerts for appending new rows or changing values are not compatible with the virtual DataSets from a publication (as shown on the left).
Are there any unsupported chart types like in Publish V1?
Yes, this is currently being worked on. These include:
- Poll Cards and Sumo tables.
- DataScience Cards: XY Line, Scatter, Predictive, Forecasting, Outliers, Vertical & Horizontal Box Plot.
How do publications handle Beast Modes?
Beast Modes are only copied to the Subscriber account if they are being used in the Cards.
What data is transferred during a publication?
Only metadata is transferred (Card titles, Dashboard layout.)
Are there any row or refresh limits or data delays to be aware of in Domo Everywhere publications?
There are no row or refresh limits and no delay in data updates when publishing data with Domo Everywhere.
Are users in the subscriber account able to edit and save changes to Cards/Dashboards Published to them?
Yes, however, any changes they made will be overwritten when the publication is refreshed. If users would like to make changes, they should Save As the Card/Dashboard to another location and make changes there as these will be independent of the Publish publication.
Troubleshooting
Publish job doesn’t show up on the subscriber side.
-
Cause 1: The instance URL was typed incorrectly or is missing the “.domo.com”.
-
Cause 2: The publish toolkit hasn’t been enabled in the subscriber instance.
Card shows broken in the subscriber instance.
-
Cause 1: PDP wasn’t enabled properly. Verify the DataSet has PDP enabled.
-
Cause 2: The job was modified and had a new DataSet added and the permission hasn’t been set.
-
The user should click through all steps when editing the Publish job.
-
-
Cause 3: A new instance was added to the job. Fix is to click through all steps and close.
Instances that are not compatible.
We currently can’t publish between pre-production instances and production instances.
Referencing invalid columns.
Breaks Publications when referenced in Card definitions, Beast Modes, and Drill Paths.
Broken Card definitions.
Cards showing “fix it” usually just need to be resaved. Most of the time, there is no visible indication the Cards have problems.
Subscription creation can take up to 10 minutes.
The layout is applied at the very end.
Requesting assistance
Email: support@domo.com
Include the following information:
- Instance(s) where behavior is occurring
- Publication Name
- Description of behavior
- Screenshot of behavior (if applicable)
- Steps to recreate behavior (if known/applicable)
Comments
0 comments
Please sign in to leave a comment.