Communicate within requests using discussion tabs

The Discussion feature (or Discussion Tab) reduces conversations about a specific request outside of Nutrient Workflow Automation (formerly Integrify) and prevents requests from bouncing back to the Requester for additional information. This centralizes all request-related information within Nutrient Workflow Automation and reduces requests routed back for clarification.

Key features of the Discussions tab

• The Discussion Tab is enabled by default, but you can disable it at the process level on the Process Details tab.

• Post comments and attach files independent of the workflow routing. You can even attach offline email discussions. To attach offline email discussions, save or export your emails from your email client to a local folder and then attach them as files to your comment.
• Make posts private so only the users you select and yourself can see the comment.
• Send an email to select people when posting a private message and only share it with those users.
• When you email a discussion post, Nutrient Workflow Automation includes a link to the request in that email, giving recipients access to view the request details.
• Discussion posts appear inline with task completions in the task history, providing a complete chronological view of all request activity.

Secure defaults for new processes

When you create a new process, the Discussion Tab has secure defaults configured to protect sensitive request information:

• Enable Discussion Tab — Checked by default
• Restrict discussions to participants — Checked by default
• Restrict access to participants — Checked by default

These defaults ensure that new processes start with appropriate security controls in place. Administrators can manually adjust these settings on the Process Detail tab if specific workflows need different access patterns.

Existing processes retain their current settings and these defaults don’t affect them.

Controlling discussion access

By default, all users who can view a request can also participate in discussions. However, you have multiple options to restrict discussion access to ensure only appropriate users can view and post comments.

Discussion security options

When enabling the Discussion Tab, you have the following security options available:

• Enable Discussion Tab — Activates the Discussion Tab for requests created from this process.
• Restrict discussions to participants — Limits discussion access to users directly involved in the request.
  • Include statically assigned users — Extends access to users with static task assignments in the process definition.
  • Include statically assigned group members — Extends access to all members of groups with static task assignments.
• Restrict access to participants — Limits who can view the request details to participants only.

Participant-based restrictions

• Restrict discussions to participants — When you enable this option, only users directly involved in the request can access the Discussion Tab and post comments. This includes:
  • The person who started the request (requester)
  • Users assigned to tasks within the active request
• Include statically assigned users — Enables users with static assignment to any task in the process definition to access discussions, even if they don’t have an active task in a specific request.
• Include statically assigned group members — Extends discussion access to all members of groups with static assignment to process tasks.

Group-based restrictions

• Restrict discussions to members of these groups — When you enable this option, only members of the selected groups can access the Discussion Tab and post comments. This option provides more granular control than participant-based restrictions.
  • Select one or multiple groups from the dropdown
  • Only members of the selected groups will see the Discussion Tab on requests
  • The Select Users dialog (when composing comments) will only show members of the authorized groups
  • This restriction applies to all requests created from this process

Use cases for group-based restrictions:

• Limiting sensitive discussions to specific departments (for example, HR, Finance, Legal)
• Restricting communication to specialized teams (for example, Security Team, Compliance Officers)
• Creating process-specific communication channels for cross-functional projects

Group-based restrictions work independently of participant-based restrictions. When you enable both types of restrictions, users must satisfy both conditions to access discussions.

System administrator access

System administrators always have full access to discussions regardless of these settings.

How access is determined per request

The system copies discussion access settings to each request when you create it. This means that permission rules remain consistent throughout the request’s lifecycle even if the process definition changes later.

If you configure a process with group-based restrictions and later remove those restrictions from the process definition, existing requests will still enforce the original group restrictions that you set when you created them.

Example

Many workflows have a form submission with several approval steps. The Approval tasks usually link back to the original form in the workflow in case an approver needs to send the request back to the requester (for example, More Information Needed). Once the requester sends the request back, it has to go through all approval steps again. This can happen multiple times.

Instead, once you launch a request, you can ask questions for the requester (or anyone else involved in the process) on the Discussion Tab, which appears along with the Request Detail and Flow View tabs. Discussions operate independently of any routing and the system tracks them along with the request. The system then automatically saves discussions along with all other request information if needed later.

To message specific users, click the User icon. This opens the Select Users dialog where you can:

• Email these users — Send an email notification to the selected users when you post the comment.
• Share only with these users — Make the post private so only the selected users can view it.

Select one or more users from the list, then click Save to apply your selections before posting your comment.

Discussion history in task history

Discussion posts can appear inline with task completions in the task history, providing a complete chronological view of all request activity.

Enabling task history integration

To show discussion posts in the task history:

1. Navigate to the Process Detail tab
2. Check the Show discussion posts in Task History checkbox

When enabled, discussion posts appear chronologically alongside task completions. When disabled, you can only view discussion posts in the Discussion Tab.

This setting is independent of the Discussion Tab security options. You can enable discussion access restrictions while still showing discussion posts in the task history.

Task history features

• Chronological ordering — The system mixes discussion posts with task completions based on timestamp, showing exactly when communication occurred relative to workflow progress
• Visual differentiation — The system labels discussion posts with "Discussion Post" type and uses an expansion panel to display full message content and attachments
• Expandable content — Click on a discussion post to expand and view the complete message text and any attached files
• Attachment preview — File attachments display with icons and truncated filenames; hover to see full filename
• Permission-based visibility — Users only see discussion posts they’re authorized to view based on the security settings you configure for the process

Benefits of task history integration

• Complete audit trail — See all communication and task activity in one place
• Context preservation — Understand the timing and context of discussions relative to workflow progress
• Improved traceability — Track when questions were asked and answered during the workflow
• Simplified navigation — No need to switch between tabs to review the full history of a request

Private messages appear in the task history with appropriate content filtering based on authorization (see Private Messages section below).

Private messages

The Discussion Tab supports private messages, enabling users to share sensitive information with specific individuals without making it visible to all discussion participants.

Creating a private message

1. Click the "New Post" button in the Discussion Tab
2. Check the "Share only with these users" checkbox
3. Select one or more recipients from the user dialog
4. Compose your message and optionally attach files
5. Click "Post" to send the private message

You must select at least one recipient when creating a private message. If you don’t select any recipients, you’ll receive an error message prompting you to select users.

Viewing private messages

For authorized viewers (sender and selected recipients)

• Can see the full comment text in the Discussion Tab
• Can see the full comment text in the task history
• Can see the list of recipients shown as "Shared with: User1, User2"
• Lock icon is visible indicating the message is private

For other users with Discussion Tab access

• See "Private message" placeholder text instead of actual content
• Can see the message timestamp
• Lock icon is visible indicating the message is private
• Cannot see the actual message content, recipient list, or any attached files

Private message restrictions

• No replies — Private messages can’t be replied to directly
• No editing recipients — The recipient list can’t be changed after posting (though the sender can edit the message content)
• No admin override — System administrators can’t view private messages unless they’re explicitly added as recipients
• Not searchable — The system excludes private message content from search results for unauthorized users
• Export handling — Private messages appear as "Private message" placeholders in exports for unauthorized users

Permission requirements

• Creating private messages — Any user with permission to post in the Discussion Tab can create private messages
• Viewing private messages — Only the sender and explicitly selected recipients can view the content
• Editing private messages — Only the sender can edit their own private messages
• Deleting private messages — Standard delete permissions apply (sender can delete their own messages)

If you enable group-based restrictions (refer to the Controlling Discussion Access section above), the user selection dialog for private messages will only show members of the authorized groups.

Best practices

Below are some best practices for using the Discussion Tab effectively and securely:

Choosing the right security model

• Use participant-based restrictions when you want to limit discussions to only those actively working on requests
• Use group-based restrictions when you want to limit discussions to specific departments or teams regardless of task assignments
• Combine both restriction types for maximum security (for example, HR processes where only HR group members who are also participants can access discussions)

Managing private messages

• Use private messages for sensitive information that doesn’t need to be visible to all discussion participants
• Remember that administrators can’t view private messages unless they’re explicitly included as recipients
• Consider whether information should be truly private or if it’s better to use group-based restrictions to limit discussion access at the process level

Task history usage

• Review the task history to understand the full context of discussions and workflow progress
• Use the chronological view to identify bottlenecks or delays between task completions and related discussions
• Leverage the complete audit trail for compliance and process improvement purposes

Process design considerations

• For new processes, review the default security settings and adjust only if your workflow requires broader access
• For existing processes, consider enabling the new security features if they handle sensitive information
• Test discussion access with different user roles and group memberships before deploying process changes to production