Best Practices: Setting Up Process Automation

Overview

This guide helps administrators, process builders, and operations managers design team structures, configure access, and assign work in Process Automation. Following these best practices ensures that processes are scalable, easy to maintain, and support effective monitoring and reporting.

The guide explains key concepts, describes when and how to use teams, and provides step-by-step guidance with examples.

Core Concepts

Processes, instances, and tasks

Process: A defined sequence of steps - often initiated by a form - that manages data, routing, and approvals for a specific business scenario, such as an HR employee status change.

Instance: A single run of a process. Each instance captures specific information (such as who initiated it and when it ran) and can be tracked and reported on.

Task: An individual step within a process instance that requires user action, such as reviewing or approving a request.

Team types

Process Automation uses two types of teams, each with a different purpose.

Assignment Teams: Groups of users who can receive tasks. You can further control task distribution by assigning roles within the team to create sub-teams of functional specialists.

Project Teams: Teams that own projects and the resources within them. With the appropriate permissions, project team members can build, manage, monitor, and report on all processes in the project.

Why use teams

Teams enable monitoring and reporting for stakeholders beyond administrators. Assignment teams and project teams support different reporting and visibility scenarios, which are explained later in this guide.

Monitoring and reporting access

Access to monitoring and reporting depends on team ownership and project permissions:

• Members of the project team that owns a project can monitor and report on all processes within that project.
• Assignment team members and other users who are not part of the owning project team must be granted External Project Access to monitor and report on those processes.
• Without External Project Access, assignment team members can only view and manage their own tasks through their inbox and cannot run reports.

Avoid putting everything in the Global project

Use the Global project as a shared library for reusable resources, not as a container for complete, end-to-end processes.

Building processes in the Global project limits monitoring and reporting access to administrators or requires overly broad permissions that are difficult to manage. Support for per-process access rights is planned for a future release.

Setting Up Assignment Teams

Step 1. Plan your team structure

Create the minimum number of teams needed to reflect how your organization actually works. Fewer, well-designed teams are easier to manage and report on.

When defining teams, consider:

• People who work together across one or more processes
• People who are assigned similar types of tasks
• Different responsibilities within a team (for example, HR Payroll and HR Benefits)
• Managers who need visibility to balance workloads or reassign tasks during absences

Create a list of teams and the users in each team. Common examples include Legal, Finance, HR, Registrars, and Sales.

Step 2. Designate team managers

After defining your teams, decide which users should be team managers. This guide focuses on the Team Manager access right.

A team manager can:

• View all tasks assigned to any member of the team, regardless of task visibility
• Reassign tasks and assign tasks to other team members, regardless of individual task security

This broader visibility is the primary difference between team managers and standard team members.

Read more about Team Access Rights.

Step 3. Choose task visibility

Task visibility controls who can see tasks assigned to the team.

• Show team tasks to all team members (recommended): Allows team members to help each other and cover out-of-office scenarios. Each user’s My Tasks view still shows only tasks assigned to them.
• Hide team tasks: Use this option for teams that work on sensitive processes where only team managers should have full task visibility.

Step 4. Use assignment roles as sub-teams

Use assignment roles to route tasks to specialists without creating additional teams. This approach keeps management and reporting centralized while limiting who receives specific tasks.

For example, an HR team may include payroll and benefits specialists, or a registrar team may handle only certain schools or majors. Assignment roles allow you to assign tasks directly to these specialists without creating separate teams.

Step 5. Create teams and roles

Create assignment roles first. You can add or refine roles later as your processes evolve.

If you already know which roles you plan to use, create them now.

[Link to Create Assignment Roles documentation]

Next, create each assignment team and assign the Team Manager access right to the appropriate users. To speed up setup, bulk-add standard team members first, then add team managers separately.

Read more about creating teams.

Example teams

HR Team

This example shows how assignment roles can route work to specialists while team managers retain full visibility and control.

Example HR Team

Team Member	Assignment Roles	Access Rights
John Smith	[General], [Benefits]	Team Manager
Jane Doe	[Payroll]	Team Manager
Paul Johnson	[General], [Benefits]	Standard Member
Alison Dear	[Payroll]	Standard Member

Tasks assigned to [General] are routed to all team members with the [General] role (John and Paul). Jane and Alison do not receive these tasks because they do not have the role. However, Jane can still view and manage them because she is a team manager.

For sensitive HR tasks, set task visibility to Hide. Team managers (such as John) can still view all team tasks, even if they do not have the specific role (for example, [Payroll]).

Registrar Team

This example routes tasks by school while allowing team managers to oversee work across the entire team.

Example Registrar Team

Team Member	Assignment Roles	Access Rights
John Smith	[School of Nursing]	Team Manager
Jane Doe	[School of Engineering]	Team Manager
Paul Johnson	[School of Business]	Standard Member
Alison Dear	[School of Psychology]	Standard Member

Team managers can see all Registrar tasks across schools. Other team members only receive and see tasks for their assigned school.

Set task visibility to Show so registrars can help each other and cover absences when needed.

Finance Team

This example uses roles to separate invoice tasks from payroll tasks while preserving manager oversight.

Example Finance Team

Team Member	Assignment Roles	Access Rights
John Smith	[Invoices]	Team Manager
Jane Doe	[Payroll]	Team Manager
Paul Johnson	[Payroll]	Standard Member
Alison Dear	[Invoices]	Standard Member

Team managers can see all Finance tasks, regardless of role. Other team members only receive and see tasks for their assigned roles.

Use task visibility Hide if payroll tasks are sensitive and should be visible only to the [Payroll] sub-team and team managers.

Effectively Assigning Tasks

Whenever possible, assign tasks to teams instead of individual users. Assigning tasks directly to users increases maintenance when staffing changes occur and limits visibility for managers and other stakeholders.

Use direct user assignments only when tasks must go to a specific person, such as:

• Employee survey tasks
• Manager approvals for access requests
• Manager approvals for performance reviews

To route work to specialists while keeping a single point of managerial oversight, assign the task to a team and select the appropriate assignment role.

When a task is rejected and returned for updates, consider routing the next approval to the previous participant so the same specialist can review the changes. To do this, configure the approval task to include the prior participant along with the relevant assignment role.

Learn more about setting up assignment roles

Learn more about using assignment roles

Setting Up Project Teams

Use project teams to give users the ability to build and maintain automations within a project. If your goal is to let users monitor and report on processes owned by another project team, see Setting Up Projects for External Access in this guide.

Example: Processes by Department

For simplicity, assume you want to build one process for each area shown in the earlier examples:

• Finance: Invoices, Payroll*
• HR: Payroll*, Benefits
• Registrar: Student registration

Note: Both Finance and HR participate in the Payroll process. The sections below describe common setup options for shared processes. Also, treat project-owning teams separately from assignment teams, even if they have similar names.

How Access Works in Process Automation

Process Automation access follows this hierarchy:

• Project-owning team > Projects > Processes

You can grant monitoring and reporting access at the team and project levels.

Recommended Approaches

Best Practice: Team-Owned Development

Onboard departments to build and maintain their own automations. Central IT can still assist, but distributed ownership scales better and helps teams realize value faster.

Pros

• Scales development across the organization
• Enables more teams to build more processes

Cons

• Can be harder for organizational administrators to audit and standardize

Recommended access roles

• Team Developer: Builds and maintains processes
• Analyst: Monitors and reports on processes

Second Best Practice: IT-Owned Development

This approach is often simpler for smaller IT and administrative teams. IT owns development while business teams primarily consume reporting.

Pros

• Simpler to administer with a small IT team

Cons

• Requires additional teams, which can increase inbox noise and ongoing maintenance

Avoid: Using the Global project for end-to-end processes

Using Global for complete processes may be convenient initially, but it limits your ability to grant stakeholders access to monitor and report on only their processes.

Pros

• Simplest to administer for IT and administrators

Cons

• To give stakeholders visibility, you may have to grant access to every process in Global

Best Practice: Team-Owned Development

Assigning Access Roles

If you already created assignment teams for Finance, HR, and Registrar, you can also use those teams as project-owning teams by assigning additional access roles.

Use the following access roles:

• Team Developer for users who build and maintain processes
• Analyst for users who monitor and report on processes

Note: Team managers can already view project resources and monitor/report on processes, but they cannot build or modify processes unless they also have the Team Developer role.

Review each team and decide who should build processes. Assign those users the Team Developer access role.

In most cases, assign the remaining team members the Analyst access role. For sensitive teams (such as HR), limit the Analyst access role to only the users who need reporting access.

Learn more about access rights

Setting Up Projects for External Access

For shared processes, decide which team owns the process. In this example, the Finance team owns the Payroll process because they will build and maintain the solution and its integrations.

After setting up Finance as a project-owning team, create the following projects:

• Finance Project
• Finance/HR Project

Finance Project: Give External Project Access to IT

If you want IT to help maintain processes, add the IT team or group under External Project Access and assign the Process Developer role.

Clear View submitted data unless IT should be able to view submitted form data.

Finance/HR Project: Give External Project Access to HR

To allow HR to access data for the shared Payroll process, add the HR team under External Project Access.

Do not assign roles. Select View submitted data only if HR needs access to submitted data.

Important limitation: Depending on your configuration, you may not be able to grant IT development access without also expanding HR’s access, or grant HR reporting access without also granting IT reporting access. Choose the configuration that best matches your requirements.

Second Best Practice: IT Owns Development

With IT-owned development, create separate project teams that include IT developers plus the business users who need monitoring and reporting access. This typically results in additional teams.

In this model:

• Project teams are used for access roles (Developer/Analyst), not assignment roles.
• Assignment roles are managed in assignment teams, not in project teams.

The final setup might look like this:

• Proj_Finance Team: Finance analysts, IT developers
  • Finance Project
  • Finance/HR Project: HR added via External Project Access
• Proj_HR Team: HR analysts, IT developers
• Proj_Registrar Team: Registrar analysts, IT developers

Tradeoff: This approach creates more teams to maintain and more teams displayed in users’ inboxes.

Avoid: Everything in Global or in a Single IT Project

If you build all the processes in the Global project (or a single IT-owned project), you cannot grant teams and stakeholders access to monitor and report on their processes without also granting visibility into unrelated processes.

This may simplify development, but it reduces the value stakeholders can get from reporting and oversight.

To move away from Global, see:

• Migrating Project Resources
• The Process Automation Deployment Manager