SQACE can currently work with data from databases, files and web services. These can be combined with each other in any way. For example, a database table can be compared with an Excel file or connected (join, union, etc.).

Yes, SQACE provides a REST API that can be used to start action runs and retrieve the results of the runs. The prerequisite for this is that on the one hand the action is marked as callable via REST API and on the other hand the calling user is also authorized accordingly.

In general, SQACE is containerized and can therefore be deployed on any VM. The installation can therefore take place on premise or in the virtual private cloud of your company. The installation can also be customized to meet specific needs for data separation, performance requirements, etc. We are happy to advise you on this.
We currently do not offer SQACE as SaaS, but this is planned for the future.

In SQACE there are mission bases and missions.

Mission Bases are separate areas that can be used to give projects or departments their own area.

In a mission base there are missions, e.g. to define subareas within projects or departments and also to authorize crew members accordingly.

A mission could be e.g. "DQ-Check CRM Data" or "Test Automation Customer Data Processing" or "Financial Data Analysis".

Any deployment levels can be defined in SQACE.

Missions can be deployed via the stages with UI support and a few clicks.
Different data connections (execution environments) are configured in different deployment levels.
Crew members can be authorized differently at different levels.

A crew member who can edit actions at the "Development" level can then switch to the "Test" level and, for example, only view actions and execute read actions there in order to use the missions deployed there with the data there.

In addition, several execution environments can be defined within a deployment level, so that crew members can execute their actions sometimes on the environment "Test-1: synthetic data" and sometimes on the environment "Test-2: mass data".

For those who really want it, SQACE offers an Excel download for query results and also test result reports, provided crew members have the appropriate permissions.

However, this is not the "SQACE way". We rather support the principle "All data stays on the platform". To this end, we provide ways to annotate, color-code, and share links to all data in SQACE at the cell level, eliminating the need for downloading.

The SQACE Storage is our internal database, where we can e.g. combine data from different sources or query results are kept for a certain period of time and can be reused. After the preset time, these are automatically deleted again.

Data in SQACE Storage is always assigned to a mission and can only be read with the appropriate authorization for that mission. Data in the SQACE Storage can also be color-coded, commented on and the link to it can be shared so that other crew members with authorization can also see it.

All tabular results in SQACE have a tab "Data Profile".

In the Data Profile there are possibilities to display table and column statistics (counts, expressions, uniqueness, extrema,...).

Furthermore, a pie chart and a column chart (histogram) are preconfigured to display value frequencies and value distributions for a column.

In addition, other chart types can be used by the user for the results and then configured as desired. (e.g. line chart)

Each action has an automatic version history for changes. Crew members can view this history and roll back to previous versions.

Also for missions, crew members can create a version snapshot with 2 clicks to restore this state later or to release the state and roll it out to other deployment levels (e.g. test or production).

Yes, all TMS that can make a REST call can start actions (such as workflows) parameterized via the SQACE REST API. All TMSs that provide an API themselves can also have the results returned to them.
This general case, however, requires glue code to connect the systems, which also allows us to address special features in the respective systems or customer-specific conventions, e.g. in test case creation.

We are also planning low/no-code integration for individual TMSs.