Creating Change Security Role Tasks for Automations

Change Security Role tasks automatically modify user security role assignments when an Automation's criteria are met. This task type is essential for access management, permission adjustments based on user progression, role promotions or demotions, and ensuring users maintain appropriate system access aligned with their current status. Change Security Role tasks eliminate manual role administration and guarantee permission changes occur at the exact moment business conditions require access modifications.

Requirements

To create and configure Change Security Role tasks for Automations, users must be assigned a Security Role with the following permissions:

Administrator System Role

Only administrators can access Automations, create Change Security Role tasks, configure role assignments, and manage task settings. Standard users, partner users, and customer portal users cannot configure Automation tasks or modify security role assignments.

Before You Begin

Before creating Change Security Role tasks, ensure you have:

• User Journey Automation: Change Security Role tasks can only be added to Automations created on the User Journey entity. If your Automation is based on a different entity, this task type will not be available.
• Security Role Strategy: Identify which security roles should be assigned or removed at different journey stages. Understand role hierarchies, permission sets, and access implications for role changes.
• Journey Builder Integration: Verify that Journey Builder is configured with appropriate phases and milestones that correspond to role change requirements.
• Role Type Compatibility: Understand that only Portal roles can be assigned through this task type. Administrator and System roles cannot be assigned via Automation for security reasons.

Creating Change Security Role Tasks

Accessing the Task Creation Interface

1. Navigate to Setup → Create → Automations
2. Click the User Journey entity Automation to which you want to add a Change Security Role task
3. In the Automation Tasks section, click New
4. Select New Change Security Role from the task type options
5. Click Next

The Change Security Role task configuration page displays two primary sections: Detail Information and Change Security Role Information.

Configuring Detail Information

The Detail Information section defines basic task properties and execution order within the Automation.

Automation (Read-Only)

Displays the parent Automation this task belongs to. This field is system-populated and cannot be modified. The link opens the Automation detail page.

Name (Required)

Enter a descriptive name for the Change Security Role task that clearly identifies its purpose and the role change being applied.

Examples of effective task names:

• "Assign Advanced Partner Role on Certification"
• "Remove Basic Access Role After Onboarding"
• "Upgrade to Premium Partner Role"
• "Add Regional Manager Role on Promotion"

Clear task names help administrators understand Automation workflows when reviewing or troubleshooting multi-task sequences.

Sequence (Required)

Enter a numeric value defining when this task executes relative to other tasks in the Automation. Lower sequence numbers execute first.

Description (Optional)

Enter notes explaining the task's purpose, business justification, or special considerations. Use this field to document:

• Why security role changes occur at this journey stage
• What permissions the new role grants or removes
• Which business milestones trigger role modifications
• Any dependencies on other tasks or user qualifications

Comprehensive descriptions help future administrators maintain and troubleshoot Change Security Role tasks.

Configuring Change Security Role Information

The Change Security Role Information section defines which security role will be assigned or removed and the action to perform.

Security Role (Required)

Click the lookup icon to search for and select a security role to assign or remove. The dropdown displays security roles that are:

• Portal roles (not Administrator or System roles)
• Active in the system
• Available for assignment to users
• Accessible based on administrator permissions

The selected security role determines:

• Which entity records the user can access
• What actions the user can perform (view, create, edit, delete)
• Which portal features and modules are available
• Data visibility scope and record-level permissions
• Navigation menu items and interface elements displayed

Security Role Selection Considerations:

Journey Stage Alignment: Select roles that align with user progression through journey phases. Basic roles for initial stages, intermediate roles for mid-journey, and advanced roles for completion milestones.

Permission Scope: Verify the selected role grants appropriate access for the user's current journey stage. Avoid overly permissive roles that expose sensitive data or functionality prematurely, and avoid overly restrictive roles that prevent users from performing required actions.

Role Hierarchy: Consider your organization's security role hierarchy. Ensure role changes follow logical progressions from less privileged to more privileged roles as users advance through journeys, or from more privileged to less privileged if journey milestones require access reduction.

Action (Required)

Select whether to assign or remove the selected security role. Two options are available:

Add

Assigns the selected security role to the user associated with the User Journey record.

When to Use:

• Granting additional permissions when users achieve milestones
• Upgrading access as users complete certification or training
• Adding role-based capabilities when journey phases advance
• Providing expanded access when qualification criteria are met

Behavior:

• If the user already has the role, no duplicate assignment occurs (task completes successfully without error)
• The role is added to the user's existing role assignments
• User retains any previously assigned roles unless explicitly removed by other tasks
• New permissions become effective immediately upon role assignment
• User may need to log out and log back in to see interface changes reflecting new permissions

Remove

Removes the selected security role from the user associated with the User Journey record.

When to Use:

• Revoking temporary or provisional access after initial journey phases
• Removing basic roles as users transition to advanced roles
• Eliminating access when users fail to meet continuing requirements
• Downgrading permissions when business conditions change

Behavior:

• If the user does not have the role, no error occurs (task completes successfully)
• The role is removed from the user's role assignments
• User retains any other assigned roles not affected by this task
• Permissions granted by the removed role are revoked immediately
• User may lose access to records, features, or data previously available through the removed role
• User may need to log out and log back in to see interface changes reflecting removed permissions

Saving the Change Security Role Task

After configuring all settings:

1. Review all configuration for accuracy
2. Verify the selected role is appropriate for the journey stage
3. Confirm the action (Add vs. Remove) matches intended access modification
4. Ensure users will retain necessary baseline access if removing roles
5. Click Save

The Change Security Role task is added to the Automation's task list and will execute according to its sequence number when the Automation triggers.

If validation errors occur:

• Check that Name is provided
• Verify Sequence is a valid number
• Confirm a Security Role is selected
• Ensure an Action (Add or Remove) is selected
• Verify the selected role is a Portal role (not Administrator or System role)

Understanding Change Security Role Task Behavior

Task Execution

When the Automation criteria are met and the Change Security Role task's sequence is reached:

1. The system identifies the user associated with the User Journey record
2. The system retrieves the user's current security role assignments
3. If action is "Add": The selected role is assigned to the user (if not already assigned)
4. If action is "Remove": The selected role is removed from the user (if currently assigned)
5. The user's effective permissions are recalculated based on updated role assignments
6. Role changes take effect immediately for new data access requests

Security role changes occur synchronously during Automation execution. There is no delay or queuing for role modifications.

Permission Activation and Interface Updates

After security roles are assigned or removed:

Immediate Effects:

• Data access permissions change immediately for new requests
• Record visibility updates based on new role criteria
• Feature access changes according to new role permissions
• API and integration access reflects updated role assignments

Delayed Effects Requiring Re-Login:

• Navigation menu changes may not appear until user logs out and logs back in
• Interface element visibility updates may require session refresh
• Cached permission checks may not reflect role changes until session renewal

Multiple Role Assignments

Users can have multiple security roles assigned simultaneously:

• Each role contributes permissions to the user's effective access
• Users receive the union of all permissions from assigned roles (most permissive)
• Adding roles expands access by combining permissions from all assigned roles
• Removing roles restricts access but user retains permissions from remaining roles

Change Security Role tasks modify individual role assignments without affecting other roles unless explicitly configured to do so through separate tasks.

Duplicate Assignment and Removal Prevention

The system handles duplicate operations gracefully:

Add Action:

• If the user already has the role, no error occurs
• The task completes successfully without creating duplicate assignments
• User's existing role assignment remains unchanged

Remove Action:

• If the user does not have the role, no error occurs
• The task completes successfully without attempting to remove non-existent assignments
• User's existing role assignments remain unchanged

This behavior ensures Change Security Role tasks can run multiple times without causing errors or creating inconsistent role states.

Failed Role Change Tasks

Security role changes may fail if:

• The selected security role is deleted or deactivated
• The user associated with the User Journey record is inactive or suspended
• The role is an Administrator or System role (not permitted via Automation)
• System permissions prevent automated role assignment
• The User Journey record is not properly associated with a user

Integration with Journey Builder

Change Security Role tasks integrate directly with Journey Builder to provide seamless permission management throughout user progression:

Journey Phase Transitions

Security roles typically change as users progress through journey phases:

Foundation Phase: Assign basic access roles providing essential portal features and limited data visibility. Users can access onboarding resources, training modules, and initial communication channels.

Intermediate Phases: Upgrade to expanded access roles as users complete training or achieve initial milestones. Additional permissions enable broader collaboration, advanced features, and increased data access.

Advanced Phases: Assign premium or certified roles when users meet qualification criteria. Full feature access, comprehensive data visibility, and specialized capabilities become available.

Maintenance or Renewal Phases: Maintain current role assignments or downgrade roles if users fail to meet continuing requirements. Expired certifications or incomplete renewals may trigger role restrictions.

Milestone-Based Role Assignment

Use Automation criteria targeting journey milestones to trigger role changes:

• When "Certification Complete" milestone is achieved → Add "Certified Partner" role
• When "Onboarding Phase" completes → Remove "New User" role, Add "Standard Partner" role
• When "Premium Tier Qualification" milestone is reached → Add "Premium Partner" role
• When "Annual Recertification" fails → Remove "Certified Partner" role

Milestone-driven role changes ensure access aligns precisely with user achievements and qualifications.

Coordinated Task Sequences

Change Security Role tasks work synergistically with other Automation tasks:

1. Change Security Role task modifies user permissions (early sequence)
2. Course Assignment task assigns role-appropriate training (mid sequence)
3. Group Member task adds user to role-specific communities (mid sequence)
4. Email Alert task notifies user about role change and new capabilities (late sequence)

This coordination ensures users receive appropriate access, resources, and communications aligned with their new role assignments.

See Journey Builder and Training and Journey Builder Integration documentation for detailed information about journey configuration and milestone tracking.

Common Use Cases

Certification Achievement Role Upgrade: When a user completes a certification journey phase (detected by Journey Builder milestone), automatically add "Certified Partner" role and remove "Basic Partner" role. This provides certified users with expanded access to advanced resources, premium features, and specialized partner communities reflecting their qualified status.

Onboarding Completion Access Expansion: When a new partner completes the onboarding journey phase, automatically remove the restrictive "New Partner Onboarding" role and add the comprehensive "Standard Partner" role. This expands access from limited onboarding resources to full portal capabilities after orientation completion.

Premium Tier Qualification: When a partner achieves premium tier status (tracked through journey progression based on revenue, certifications, or other criteria), automatically add "Premium Partner" role. This grants access to exclusive programs, priority support, enhanced marketing resources, and premium-only features.

Training Prerequisite Enforcement: When users complete foundational training courses (tracked through Journey Builder integration with Training Module), automatically add "Intermediate Training Access" role enabling enrollment in advanced courses. This enforces prerequisite completion through role-based course visibility.

Temporary Access Revocation: When a partner's compliance certification expires (detected by journey milestone "Annual Compliance Expired"), automatically remove "Compliant Partner" role restricting access to compliance-required features. This enforces ongoing certification requirements through role-based access control.

Regional Promotion Role Assignment: When a user is promoted to regional manager status (tracked through journey phase "Management Promotion"), automatically add "Regional Manager" role providing access to team oversight dashboards, reporting tools, and management resources appropriate for the leadership position.

Best Practices

Plan Role Progression Strategy: Design security role hierarchies that align with journey progression before creating Change Security Role tasks. Map journey phases to role assignments ensuring logical access progression from restrictive to permissive as users advance. Document role relationships and progression paths for consistent implementation.

Maintain Baseline Access: When removing roles, ensure users retain necessary baseline access through other role assignments. Completely removing all roles may lock users out of the portal. Consider creating separate Automations that coordinate role additions and removals to prevent access gaps during transitions.

Test Role Transitions Thoroughly: Before activating Automations with Change Security Role tasks, test with sample user journeys verifying role changes grant expected permissions, removed roles do not prevent necessary access, users can view appropriate interface elements, and data visibility aligns with role definitions. Role permission errors are difficult to troubleshoot without comprehensive testing.

Communicate Role Changes to Users: Use Email Alert or Feed/Message tasks to notify users about role changes, explaining new capabilities or restrictions. Inform users they may need to log out and log back in to see all interface changes. Clear communication prevents confusion about changed access or unexpected feature visibility.

Coordinate with Training and Rewards: Sequence Change Security Role tasks with Course Assignment tasks and Rewards redemption to provide comprehensive milestone recognition. Role upgrades combined with training access and reward points create compelling progression experiences motivating continued journey advancement.

Monitor Role Assignment Patterns: Regularly review security role distribution resulting from Automations. Unexpected role assignment volumes may indicate overly broad Automation criteria, while low volumes may signal restrictive rules preventing qualified users from receiving appropriate access. Adjust criteria to achieve desired role distribution.

Document Role Change Logic: Use the Description field extensively to explain why roles change at specific journey stages, what permissions are granted or revoked, and what business requirements drive the access modifications. Clear documentation helps administrators maintain role strategies as security models evolve.

Avoid Administrator Role Automation: Never attempt to assign or remove Administrator or System roles through Automation. These role types are intentionally restricted to manual assignment preventing accidental privilege escalation. Assign only Portal roles through Change Security Role tasks maintaining appropriate security boundaries.

Plan for Role Hierarchy Changes: When modifying security role permissions or hierarchies, review all Change Security Role tasks to ensure they still provide appropriate access. Role permission changes can affect Automation behavior without requiring task reconfiguration, potentially creating unexpected access patterns.

Troubleshooting

Roles Not Being Assigned or Removed: If security roles do not change when Automations trigger, verify the Automation is active, rule criteria match the triggering User Journey record, the selected security role still exists and is active, the selected role is a Portal role (not Administrator or System role), the user associated with the User Journey is active, and the task's sequence number is correct. Ensure the Automation is based on the User Journey entity.

Users Cannot Access Expected Features: If users do not gain expected access after role assignment, verify the assigned role includes necessary permissions for target features and records, the user has logged out and logged back in to refresh session permissions, no other roles with restrictive permissions override expected access (least permissive rules apply in some cases), and Security Role configuration has not changed since task creation. Test role permissions manually by assigning the role to a sample user outside of Automation.

Users Lost Access After Role Removal: If users lose more access than intended after role removal, verify users have other role assignments providing baseline access, removed roles did not include critical permissions not available through remaining roles, and role removal was intentional (not accidental configuration). Consider adding roles before removing old roles to prevent access gaps during transitions.

Administrator Role Cannot Be Assigned: If task creation fails when selecting Administrator or System roles, this is expected behavior. Administrator and System roles cannot be assigned through Automation for security reasons. Select Portal roles instead, or assign Administrator roles manually outside of Automation workflows.

Duplicate Role Assignments: The system automatically prevents duplicate role assignments, so this should not occur. If users appear to have duplicate roles, the issue likely involves multiple tasks in different Automations assigning the same role, or manual role assignments combined with automated assignments. Review all active Automations and manual role assignments to identify sources.

Interface Not Reflecting Role Changes: If data access changes but interface elements (navigation menus, buttons, tabs) do not update, instruct users to log out completely and log back in. Interface changes often require session refresh to take effect. If issues persist after re-login, verify role permissions include visibility settings for target interface elements.

Wrong Role Assigned or Removed: If incorrect roles are modified, verify the Security Role selection in task configuration matches intended role, check the Action selection (Add vs. Remove) is correct, review all active Automations to identify potential conflicts or overlapping role modification logic, and confirm Automation criteria target appropriate journey milestones. Test with sample journeys before broad deployment.

Role Changes Not Persisting: If roles appear to change but revert to previous states, verify no other Automations immediately reverse the role change through conflicting tasks, no manual administrators are modifying roles concurrently with Automation execution, and system synchronization with CRM (if integrated) is not overwriting portal role assignments. Review system logs to identify sources of conflicting role modifications.

See Troubleshooting Automations documentation for additional problem resolution guidance.

Related Documentation

Supporting Resources:

• Journey Builder
• Security Roles

Jump to Automations Checklist

<< Creating Activity Tasks for Automations | Creating Slack Message Tasks for Automations >>