Skip to content
LogScale Self-Hosted
This is an archived version of the documentation downloaded from LogScale Documentation Archives. Up to date documentation, and documentation for later versions, is available on LogScale Documentation

# Understanding Your Organization

An organization is the basic entity used to organize your LogScale SaaS instance.

## Organization Owners

Within an organization, one or more users will be assigned as an Organization Owner. They will have full access to all available actions within the organization. See Manage Users and Permissions for more details.

## Organization Owned Queries

##### Security Requirements and Controls

- `Change persistent queries to run on behalf of organization` permission

- `View permission tokens` permission

When running queries within LogScale, the query is run as the user that started or created the query. This includes triggers and shared dashboards. Because users can be removed, or have their permissions to run queries revoked, running persistent queries as an individual user can sometimes lead to queries failing, or cause further actions and sequences to fail due to a change of permissions for the user.

As an alternative, an organization can own the queries of specific assets within a LogScale instance. Organization ownership ensures that queries don't unintentionally stop running when either the permissions of a user changes — or because the user is removed. Instead, queries will keep running even despite the status of the user who created it.

To be able to create organization owned queries you'll need the permission identified as, `Change persistent queries to run on behalf of organization`.

For example, suppose you have a query that executes as part of an alert, and then triggers the file upload action, with the standard user query model, the alert and the action would both fail once the user was deleted from the system. With the Organization User model, the query will continue to execute even when the user has been removed from the system.

Organization owned queries:

- Are queries that are owned and executed by the organization; even if the user that created them has been removed the queries will be executed within the system.

- No extra permissions needed that would otherwise be needed at runtime when owned by a user.

- Only available to edit by users with the corresponding organization query ownership permissions; even if they are a part of the organization.

Organization query ownership is a permission applied at the role level. If multiple roles have been assigned to the same user and one contains organization query permissions, the user will have this privilege. `View permission tokens` create queries with organization ownership.

Organization owned queries can be used for:

> Scheduled searches

> Triggers

> Share Dashboards

Activity Recording for Organization Owned Queries. When running queries operating using the Organization Owned queries model, activity may be recorded in the system repositories humio-activity or humio-audit identifying as the `orgUser` operation type. Queries executed using this model will be executed using an ephemeralUserToken.

### Enabling Organization Owned Queries for a Role

To grant a user the ability to change the query model so that queries can be executed as organization-owned queries, you need to edit their role.

- Go to Organization Settings using the User menu icon and select Roles in the list of options on the left.

- Create a new Role by click +Add or select an existing role.

- In the list of available privileges for the role, choose Change persistent queries to run on behalf of organization.

Once enabled, within the dialogue for configuring a query, the user will see an option to Run on behalf of organization, as in the example below taken from creating a new alert:

#### Viewing Queries without Organization Ownership Permissions

Users that do not have the permission to enable organization ownership for queries, will be unable to edit persistent queries that have been configured to run on behalf of the organization.

For example, when attempting to edit an alert that has been created by a user that does not have Organization Ownership permissions on an alert configured to run as the organization, the user can only view the alert configuration:

### Updating Organization Ownership for Existing Queries

Persistent queries is a common term for triggers and shared dashboards. To update multiple existing persistent queries so that they run as Organization Owned queries the batchUpdateQueryOwnership() GraphQL mutation can be used. This enables you to batch update persistent queries and supports updating with different level of granularity:

- All persistent queries under list of views and repositories.

- A concrete list of persistent queries.

- All persistent queries under the entire organization.

Navigate to the Accessing GraphQL using API Explorer or client such as cURL or Postman to run the batch update. For example, to convert all persistent queries within your organization, run the following mutation:

graphql

    mutation {
      batchUpdateQueryOwnership(input: { targetType: Organization, ids: [] })
    }

The `targetType` can be `View`, `PersistentQuery` or `Organization`, as noted above.

The ids is an optional argument that lists the ID of each asset to which the query model should be modified. For instance you can select the PersistentQuery type and provide a set of alert ids to update.

### Organization Owned Queries and Query Prefixes

The use Organization Owned queries are incompatible with query prefixes applied to a group. A query prefix is a default search filter applied to queries for a given group. Enabling the organization owned queries permission on a role applied to a group for a given view will require the configured query prefix to be removed, as shown in the dialog below.

When editing the role and enabling organization owned queries you will be presented the removal dialog:

Check that you are happy to remove the query prefix, then tick the box and click Save changes

#### Enter search term