This Custom Variable, when set to "true", will automatically create all new users as Day Pass users. The default value of this variable is "false". This variable is relevant only if you have the Day Passes license component.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Make all new users day pass users.
    bp.Vars.DefaultNewUsersToDayPass = true;
}

If a user is in any of the groups specified by this variable, the user will be able to access the delegation administration page, even without the “User Admin” setting enabled in his user profile.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    bp.Vars.DelegationAdminGroups = "Delegation Users";
}

This variable enables you to control whether built-in users can ask Process Director to remember their session so they don’t have to log in each time they visit Process Director.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Allow users to use 'Remember Me' option
    bp.Vars.fAllowLoginRememberMe = true;
}

This variable enables you to control whether built-in users can retrieve their passwords if they are forgotten. If set to true, a prompt will appear on the login page. Development systems that use the TestUserEmailAddress won't send password reset request email to the TestUserEmailAddress, but will, instead, send them to the requesting user.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Allow users to retrieve passwords
    bp.Vars.fAllowRetrievePassword = true;
}

Users in groups are automatically added to a partition when the group is added to the partition. They are implicitly added through their group membership. This option, when set to "true" will prevent this implicit user addition, which means that users will have to be explicitly added to a partition to be part of it.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    //Disables adding users to a partition implicitly.
    bp.Vars.fDisableImplicitPartitionGroupUsers= true;
}

This variable will, when set to "true", prevent a disabled user from being renamed and preventing a new GUID from being applied during an update/synchronization. The default value for this variable is "false".

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Prevent disabled users from being renamed
    bp.Vars.fDisableUserRenameOnDisable = true;
}

Setting this variable to true will, when shared delegation is enabled, display the next task to the delegate automatically, if the principal assignee of the current task is also the principal assignee of the next task. This variable is set to false by default.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Automatically display the next task to the delegate
    bp.Vars.fSharedDelegationNextTask = true;
}

This flag variable determines whether users are added to already-running Timeline activities and Workflow steps when they join a group that is assigned as a participant on that activity or step. If set to "true", Process Director searches for running instances whose participant list is defined by the group, and adds the new member to each one. If set to "false", the user only appears in instances that start after they join the group. The default value of this flag is "false".

The group membership change can come from any source. An Active Directory synchronization, an administrator editing the group in the Users and Groups page, and an SDK call all trigger the same behavior.

Two behaviors of this variable are worth understanding before enabling it.

Task notifications are sent regardless of the activity setting. A user added to a running activity this way receives a task assignment email even when the activity or step has its notification setting turned off. Process Director treats the addition as an administrative task assignment, and that path sends the notification without consulting the per-activity setting. Setting fListenToEmailSetting suppresses this. See the entry for that variable, including its wider effects.

Turning this on does not affect existing group members. The flag acts only when a membership is added. Users who are already in the group when the flag is enabled are not added to anything that is already running. Only memberships created afterward trigger the behavior.

This variable governs additions only. Removing a user from a group has no effect on activities or steps that are already running. A user who leaves a group keeps any task they already hold, and will not be assigned tasks in instances that start afterward.

Customers running an Active Directory synchronization sometimes attribute task cancellations to group removal. The two are unrelated.

Task cancellation is a consequence of disabling a user, not of removing them from a group. When a user is disabled, Process Director cancels every active Workflow step and Timeline activity assigned to that user. An AD Sync that no longer matches a user will disable them, and their tasks are canceled at that point.

If a later synchronization re-enables those users, and fStartUsersAddedToGroup is set, they are added back into the running activities, and each addition generates a task assignment notification as described above.

Group membership changes and user disabling are separate things, and it is worth being explicit about which one does what, because they are easy to conflate.

Removing a user from a group does not cancel or remove any task the user already holds. It only changes which future instances they are assigned to.

Disabling a user does cancel their tasks. When a user is disabled, Process Director cancels every active Workflow step and Timeline activity assigned to them. An Active Directory synchronization that no longer matches a user will disable that user, and their tasks are canceled at that point. So a synchronization can appear to cancel tasks, but the cause is the disabling, not the group change.

Two settings limit how many users a single synchronization can disable, and both are worth reviewing on any profile where this matters: nMaxUsersToDisableOnSync and nMaxPercentUsersToDisableOnSync.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    bp.Vars.fStartUsersAddedToGroup = true;
}

By default, users are allowed to delegate tasks to any other user. Setting this variable to “true” restricts the user's ability to set delegations, and limits delegations only to other users who belong to the same group as the delegating user.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // Restrict delegation to the same group as delegator
    bp.Vars.fTurnOnDelegationGroups = true;
}

This variable enables you to set the maximum number of seconds to elapse prior to automatically logging out a user for inactivity. Once the configured time limit expires, the user will be logged off, and will be forced to re-authenticate to access the system again.

Example

public override void SetSystemVars(BPLogix.WorkflowDirector.SDK.bp bp)
{
    // This will set the maximum inactivity time to 2 hours.
    bp.Vars.nUserInactivityTimeoutSecs = 60*60*2;
}