As mentioned in the article Overview of a Customer Account (aka Worksoft SaaS Domain, a customer can use their Worksoft SaaS Domain for any number of automation projects/initiatives  for testing any number of applications (products), and can authorize any number of users (employees, vendor consultants/contractors) to any or all of the projects within their domain. This article defines projects, products and users within a Worksoft SaaS domain and explains the relationships between those entities.

In Worksoft SaaS, a 'Project' represents a unique manual testing (or automated testing) initiative you may have within your company. For some of you, such an initiative typically involves or covers the testing across one ore more applications. For others such an initiative may involve multiple modules within an application. In Worksoft SaaS, 'Project' is an entity that you can use as a 'shell' within which all test automation artifacts that help you meet the testing objectives of a unique testing initiative within your company.

There can be any number of projects within a customer's Worksoft SaaS domain. There are no restrictions on the maximum number of projects you can set up within your Worksoft SaaS domain. It is a one-many relationship between an Worksoft SaaS Domain and Project entities within Worksoft SaaS.

Please note that the test automation artifacts of a project cannot be accessed from the context of others projects within your Worksoft SaaS domain. Each project, therefore, can be treated as black box, if you will, within which all test automation artifacts reside. This will help you determine whether or not you should create a project for your testing initiative.

In the illustration below, you can see that there are two different projects called 'Project A' and 'Project B' and the automation artifacts for each are self-contained within each of those projects.

In Worksoft SaaS, a 'User' represents an individual that can access and utilize the test automation artifacts and/or reports that are available within/across one or more projects of your Worksoft SaaS domain. In real life, these individuals typically are your company's employees or vendor consultants/contractors or your partners' employees. Worksoft SaaS allows the creation of user accounts for non-human (machine) users as well that can be used to schedule automated tests to be executed, mostly unmanned. Please click here to know more about user types supported in Worksoft SaaS.

There can be any number of users within a customer's Worksoft SaaS domain. There are no restrictions on the maximum number of users you can set up within your Worksoft SaaS domain. Users are set up first at the Worksoft SaaS domain level and then they are optionally but typically authorized to access one or more projects based on their role within the testing initiatives/projects of your company. It is a many-many relationship between a User and Project entities within Worksoft SaaS. In other words, many users can have access to a specific project and a specific user may have access to more than one project.

One of the users that is authorized to have access to a project in Worksoft SaaS must be designated as the 'Project Lead' for that project. There cannot be more than one project lead for a project. A project lead has a number of special 'privileges' in Worksoft SaaS. For example, the project lead can configure the project and set up preferences that can be shared with others that have access to the project.

There are two different roles that a User can have within a Worksoft SaaS domain.

• Administrative Person User Role: Users with this role have privileges to set up new projects and administer them, set up new users and administer them, have access to reporting across projects including those that summarize/detail the Worksoft SaaS subscription usage.


•  Non-Administrative Person User Role: Users with this role have privileges to access the test automation artifacts within one or more projects and to generate and benefit from the various analytics and reports available within those projects. By default (meaning unless you explicitly grant them 'Administrative Person User' role), all users within a Worksoft SaaS domain have the role of 'Non-Administrative Person User'.
  

The illustration above will help you understand the relationships between Users and Projects and Users and a Worksoft SaaS domain well. You can see for this illustration that:

• There are 6 different users our of which 4 have the role of 'Non-Administrative Person User ' and the rest have the 'Administrative Person User ' role.
  


• User #1 is the Project Lead for Project A and User #6 is the Project Lead for Project B.


• Please note that a user within a Worksoft SaaS domain does NOT need to have the role of a 'Administrative Person User n' for he/she to be a 'Project Lead' for a project (as is the case for User #1 in the above illustration).
  


• Users #2 and #6 have access to both projects.


• User #3 with the role of 'Administrative Person User ' is not authorized to granted access to any project. This user can set up and administer projects and users and access reporting across projects even though he/she cannot access the test automation artifacts within either of the two projects.
  


• User #6 is a Project Lead for Project B but is not a Project Lead for Project A for which he/she also has access to.

User accounts that are set up can be inactivated any time if such a need arises. For example, if an employee or consultant leaves your company and you want to inactivate their user account within your Worksoft SaaS domain, you can do so.

As part of the software development life cycle of your application or product you must be using one or more pre-production environments (like Dev/Integration, QA, UAT) along with a production environment. In Worksoft SaaS, an 'Environment' entity is used to represent each of those environments that you use within your projects where your applications are deployed and tested.

There can be any number of environments within a project in Worksoft SaaS There are no restrictions on the maximum number of environments you can set up for a project within your Worksoft SaaS domain. It is a one-to-many relationship between a Project and Environment entities within Worksoft SaaS. In other words, many environments can be set up and used within a specific project. An environment set up within a project within Worksoft SaaS cannot be used by another project within your Worksoft SaaS domain (remember, a project is like a container within which all entities that belong to that project).

In the illustration above, you can see that Project A has 3 Environments and Project B has 2 environments. Please note that even if two projects use the environments that have the same name, you must set them up in both projects separately. For example, if all real life projects use production and QA environments within your company, in Worksoft SaaS you must set up those environments in each of the projects separately. But don't worry. It is extremely easy for you to do that. Anyways, this is a one-time task for you for each project you set up within your Worksoft SaaS domain in most cases because new environments usually don't come in your SDLC landscape.

In Worksoft SaaS, 'Product' is an entity that allows you to group your automation test scripts. In real life though, it may represents a specific software application or product OR could represent a subset of functionality (say a few modules or components) within your application suite.

There can be any number of products within a project set up in your Worksoft SaaS domain. There are no restrictions on the maximum number of products you can set up. However, at least one is required. Actually one is automatically created named after your Project. It is a one-to-many relationship between Project and Product entities within Worksoft SaaS. One Project can have multiple Products but a Product belongs to a single Project.

In the illustration above, you can see that:

• Within Project A, there are two different products called 'Product I' and 'Product II'. The former is a Web Application accessible via Desktop and Device Browsers whereas the latter is a Native Mobile App.


• Within Project B, there are two different products called 'Product X' and 'Product Y', both of which are Web Applications. The former is a an application accessible by all the customers whereas the latter is an administrative app that is only accessible by the employees of the company.


• With the above two examples, you can clearly see that Worksoft SaaS does not dictate what deserves to be a product (or not). Having said that, a general guideline exists. If you have to develop automated test scripts separately for a grouping of functionality/features, you may want to define that grouping as a Product within your Project.


• Please note however that test automation scenarios and run definitions (more on this later) that you set up within your project can utilize automated test scripts from multiple products. It is just that the lowest level test automation artifact called 'Test Scripts' are at the Product level and hence belong to a single Product.

In Worksoft SaaS, you can easily allocate (distribute) the capacity and concurrency available within the subscription plans that your Worksoft SaaS domain is entitled to (via contract) across the various projects and to users within those projects. Other articles in this knowledge base cover that topic. For now, just be assured that Worksoft SaaS gives you that flexibility.