- style
YOU ARE CURRENTLY ACCESSING AN OUTDATED VERSION OF THE ZOOLA HELP DOCUMENTATION
Go to https://help.zoola.io for up-to-date documentation, videos, walkthroughs, and case studies.
Domains in the Zoola Workflow
- Zaqir Virani (Unlicensed)
Domains are the fundamental first step in the Zoola™ Workflow. Domains are customized connections to your data source that provide access to specified data instead of the entire data source.
LMS data sources can contain an overwhelmingly large amount of information—a Domain functions as a way to filter out unnecessary data right from the source. Ad Hoc Views are based on Domains, and the creation of a View is entirely dependent on the fields and measures selected from the specified Domain.
Lambda Zoola™ includes many pre-built Domains in the Public folder of the Repository. You can also use the Domain Designer to create custom Domains, or to copy and configure an existing Domain to suit your reporting and analytics needs.
Domains can be further separated into Domains and Domain Topics. Typically, you base the decision to use Domains or Domain Topics on the complexity of the data needed for your business needs. You can also opt to use saved Reports and templates, if necessary.
The following use-cases present two scenarios in which a Domain or Domain Topic is preferable to a saved report:
Case A | Case B |
|---|---|
Domains and Domain Topics can be designed to give users great freedom in designing reports. There are also security features that prevent unauthorized access to data. | Administrators can create very targeted Domains and Domain Topics, using repository access permissions to make sure users cannot modify them. |
In Case A, a Domain could contain dozens of tables in several unjoined sets, limiting initial filtering, but effectively defining a strong data-level security policy. Users of this Domain might see only a single set of tables, because of their security permissions. They could then perform their own filtering, re-label columns for their own needs, and save their settings as a Domain Topic for future use in other Ad Hoc views. In this case, there might be only one Domain within the organization, but there would likely be many Domain Topics that users have created for specific needs. | In Case B, Domains can be used to perform complex joins, filter data, apply formulae to calculate new columns, and select sets of columns for specific users or specific report types. Perhaps the report types also require internationalization—the administrator would then create corresponding locale bundles and a single Domain Topic. In this scenario, there are many specific Domains, and each would have corresponding locale bundles and a single Domain Topic. Users would have a wide variety of Domain topics to choose from, each for a specific purpose. However, they would have no opportunity to access the Domains to perform their own filtering. |
The preceding examples illustrate two extreme cases, but there are many common scenarios that combine some degree of both scenarios. The number of users in your production environment and their level of proficiency also determine your general use cases. A small number of users who understand their database might be given administrator privileges to define complex Domains as an extension of the Ad Hoc view design process. On the other hand, with large numbers of users or with users who have limited database skills, administrators will want to create Domains that help the users meet their business goals. Using a Domain instead of a Topic has the following advantages:
Domains can be created directly through the server's user interface.
Domain creators can write SQL queries, joins, filter expressions, and security files to specify what data can be accessed, as well as labels and locale bundles to specify how the data appears.
When designing a report based on a Domain, the server can optimize database access to allow editing of reports that access huge datasets.
A Domain design typically includes data filtering, but users who create reports using the Domain can filter data even further. Users can select a subset of columns to appear in the Ad Hoc Editor and give them custom labels—users can then filter the data for each column.
Users who create reports can design prompts for input from report readers to filter data that appears in the document.
Copyright © Lambda Zoola™