The Anatomy of a DataBlock



When talking about institutional reporting, it’s easy to get lost in a discussion of the data itself. What information should a given report include? How do these two metrics correlate (or not) with one another? Which definition of ‘FTE Student’ are we using? While understanding the nature of your data is critical to useful institutional reporting, it can be equally critical to understand the way your reporting tools organize data. The better you understand your tools – and what they’re capable of – the easier it is to digest and interpret the massive of amount of institutional data at your fingertips.

In the case of Argos, any task a user performs is based upon a DataBlock. Any form you design, any dashboard you build, and any report you run will be done within the scope of a particular DataBlock. But even though DataBlocks are the starting point for everything an Argos user does, defining what a DataBlock actually is can be surprisingly difficult.

So, what is a DataBlock, really?

A DataBlock is just a word we basically made up. Argos allows you access to your data. A block can be a lot of things, but we use it here in the programming sense: “[a block is] a group of declarations and statements treated as a unit” (definition from Wikipedia). DataBlocks can contain an abundance of information or none at all. They can include a complex array of forms, objects, and reports (more on this in a moment), or they can consist of a single, simple query to return one specific data set.

The easiest way to understand the role of a DataBlock is as a container. Every time an Argos user creates a new DataBlock, they’re essentially creating a new, empty box. By adding objects—which are used to define the data returned to the DataBlock—users “fill” the box by displaying data from their institution’s databases or data warehouses. Users can also design forms that include elements like charts, OLAP cubes and multi-column lists to display the data. They can also generate reports based on the data returned, which can be printed, distributed, and exported. Since every institution has a variety of departments, each with different reporting requirements, DataBlocks can be used to present relevant data in a way that suits a particular department’s needs.

Guide to key DataBlock elements

When designing a DataBlock—the form design is used to create individual “pages” for the DataBlock, and the report query contains the SQL query that allows end users to generate reports using the data returned. Report writers can design one or more reports.  The dashboard allows users easy access to all forms and reports.  These four elements make up the anatomy of your average DataBlock.

Below is a little more detail on the role of each element:


The dashboard is the control panel for the DataBlock, providing end users with a visual interface to all the pieces of a DataBlock.  Uses can constrain and interact with the data being returned. Dashboards are made up of all of the forms, reports, control objects, graphics, OLAP cubes, and any other visual elements the DataBlock designer wants the end user to see. Dashboards also include controls that allow users to save their variable selections for future use.

Report Query

The report query is the part of the DataBlock which contains the SQL statement to return the desired data.  Typically, the SQL refers to objects on the forms to gather input from the end users. While not every DataBlock requires a report query, if the end user wants to produce any kind of report, the DataBlock must have a report query. Although DataBlocks can include many reports, they will only have one report query.


Forms make up the individual “pages” of the DataBlock’s dashboard. Forms typically include variables, which collect input from the end user. When an end user chooses a value for a particular variable, it constrains the data returned. Forms can also contain visual elements to display Charts, OLAP cubes, data lists, graphics, and other visual elements can be added to forms to visually represent the data, making it much easier for the end user to interpret.

Reports Generated using the data returned by the report query, reports are the final product of the DataBlock. They can be used to present the data outside of Argos—on paper or in a file. Banded reports allow end users to design formatted reports with groupings and subtotals.  Users can print banded reports directly or email them as PDF files. Comma-delimited and extract reports deliver the data in various file formats, making it possible for users to easily work with the data outside of Argos.

Like this blog?

You might also like this On Demand webinar:

Related Posts

Cybersecurity Trends and Threats in Higher Education

Cybersecurity Trends and Threats in Higher Education

It is undeniable that the historic events of 2020 created long-lasting changes in work and learning environments across the globe. In higher education, students, faculty, and staff realized that it was possible to successfully work, learn, and teach from home....

Evisions CO-OP: Top 10 Most Viewed Argos DataBlocks

Evisions CO-OP: Top 10 Most Viewed Argos DataBlocks

The Evisions CO-OP User Community is a collaborative place where clients can share ideas, experiences, development, forms, DataBlocks, and reports with their peers. To give you an idea of what fellow Argos users are doing and looking at, we present the Top 10 Most...

Navigating the Evisions Customer Community

Navigating the Evisions Customer Community

The Evisions Customer Community has always been an invaluable tool for clients. It serves as a resource for peers in higher ed to share knowledge and find answers. On May 7, 2019, a new community portal was launched. Why? Because we listened when our clients told us...


1 Comment

  1. Tim

    I am attending some Argos training soon. Thank you for the clarification/definition of the DataBlock! Looking froward to the training.


Submit a Comment

Your email address will not be published.

Share This