How Atomic Scope enforces user access policies? | Atomic Scope

How Atomic Scope enforces user access policies?

Archana sukumaran


Category: Atomic Scope

Posted: June 28, 2022

Security is often the most overlooked but most important feature in many custom end-to-end functional monitoring solutions. Security means user access control and auditing of their privileged system actions. This blog will give you a clear picture of user access policies in the Atomic Scope.

Atomic Scope uses windows authentication as the identity mechanism. To get access to Atomic Scope, every user needs to be part of the Atomic Scope portal. We can add new users in the User Management section of the settings page.

The user will be able to access the atomic scope portal after being added to the system. All admin users will have access to every workspace and business process by default. To access data, non-administrative users must have access to a certain workspace/business process.

There may not be a need for more than a few admin users in most circumstances. Because most policies may be set up at the workspace/business process level.

In the user management area, we can also add the group. If we grant access to a group, it will be accessible to all members of the group.

Coarse-grained control

A User Access Policy lets administrators authorize who can take action on a specific workspace and business process, and also by giving you full control and visibility to manage the reprocess settings and archived messages.

High-level hierarchy

Coarse-grained control

Workspace Level

Workspace Owner – The user can make changes to the workspace like full access to business processes on that workspace, adding users, etc.

Workspace User – The user can access all business processes within a workspace.

Workspace Level

Fine-grained control

Rather than giving users access to the entire application, you can give them access to certain workspaces or business processes. For example, within a workspace, users can give access to a specific business process.

Business process level

Business Process Owner – The user will be able to edit, delete and add users to the business process. Users can view all the activities for the specific Business process.

Business Process Reader – The user will be able to view the business process but will not be able to change it. This user will be unable to access the portal’s settings section. They can only view transactions and cannot reprocess messages or view the message body.

Message Content Viewer – Users can view the archived messages in the tracking portal. Users can download the message body But they do not have access to reprocessing.

Message Reprocessor – The user can reprocess the respective selected transaction in the tracking portal. Users can view the message body as they have access to reprocessing. But they don’t have access to modify the business process.

Business process level

Use Case

We have multiple departments and teams working in a vast organization. We also have sensitive data to deal with. As a result, we will not be able to provide full access to all users. It will have an impact on the economy and security.

For instance, an administrator can grant access to a given business process to a specific team. That group can only handle its own transactions and business processes. We can provide specific access to their team members, such as message content viewer or reprocessor, if necessary.

Feature Access Matrix

This role-based feature access matrix provides the different levels of permissions for each role defined



Any number of business process level roles can be assigned to workspace users. However, if we do not assign any access at the level of the business process. One workspace user cannot access any actions on the portal.

No other roles can modify business processes besides the business process owner. They can only see how business is conducted (Transaction, stages, properties).

How to assign users/groups for reprocessing

Reprocessing is a crucial component of Atomic Scope. The transaction would fail if a message received from the relevant service is invalid or contains data that is not correct. Atomic Scope brings the ability to reprocess the messages to web endpoints.

As was previously mentioned, Atomic Scope allows us to add users and groups. There may be thousands of records that need to be reprocessed in large organizations. Therefore, the administrator is unaware of which transactions have been reprocessed and by whom.

We can assign users/groups for reprocessing for a specific transaction.

  • Only administrators and business process owners can be able to assign a transaction for reprocessing to users or groups.
  • assign users/groups for reprocessing
  • While assigning a user/group, you can also leave them a note to indicate why this transaction has been assigned to them and/or provide any other instructions.

We can assign the reprocessing of a transaction to multiple people or groups. If you are assigning two users or groups for a particular transaction, all of them will receive the same intimation message.

What do the colored icons signify?

Take note of the user symbol in the second column. It is used to show if a transaction has already undergone reprocessing or not.

Yellow – Waiting to be picked up
Green – Done, reprocessing has been complete
Gray – Not assigned to anyone

colored icons
  • The user can acquire the transactions that are assigned for reprocessing by searching for AssignedTo = “me.”
  • ReprocessingStatus!=”done” allows us to retrieve the unprocessed transaction that has to be reprocessed.
  • Additionally, we can look for transactions that were allocated to different users, such as AssignedTo = “KOVLTP006Rob” By domain name should be specified.

Audit logs

The API requests and administrative actions that change the settings or tracked activities of the Atomic Scope portal are logged in the audit log.

Maintaining a record of the numerous actions taken by users is the primary goal of audit logs. The audit logs are always turned on.

The action may involve changing the setup of the Atomic Scope Portal or altering a user’s role.


We would like to draw attention to the fact that user access policies do not work on their own; rather, how well they work depends on the roles assigned.

We anticipate that this user access policy will be valuable and particularly relevant to consumers who want to assure a distinct separation of concerns.

Author: Archana sukumaran

Working as a Software engineer (QA) in Atomic Scope.