Issue

Web Activity reporting for unmanaged devices does not always accurately reflect the policy context under which the request was filtered.

When Smart Shield activity cannot be matched to a rostered user, Web Activity may report the district root/default policy rather than the policy associated with the Smart Shield group handling the traffic.

This can create a misleading administrative record.

Current Behavior

Lightspeed has indicated that when a user can be matched to a rostered identity, Web Activity can display the policy associated with that user.

When no user match can be made, the reported policy may fall back to the district root/default policy.

For unmanaged devices using Smart Shield, this does not necessarily represent the actual policy context applied to that traffic.

The Smart Shield is already assigned to a group, and that group has an associated policy relationship.

Operational Impact

Incorrect or misleading policy attribution creates unnecessary difficulty when troubleshooting unmanaged-device activity.

Administrators may see a request associated with the district default policy and reasonably conclude that the device was filtered under that policy, even when the Smart Shield group represents a different intended policy scope.

This complicates:

policy troubleshooting;

Smart Shield validation;

unmanaged-device investigations;

reporting consistency;

verification of policy changes;

support escalation;

audit review.

Web Activity should accurately represent the filtering context that produced the result.

Requested Enhancement

For unmanaged Smart Shield traffic, Web Activity should report the policy associated with the Smart Shield or Smart Shield group whenever that relationship is known.

The reporting logic should use the most accurate available source of policy attribution.

A preferred order would be:

Matched user policy, where a valid user identity is available.

Smart Shield group policy, where the traffic is associated with a configured Smart Shield group.

District root/default policy only when no more specific policy context is available.

Example

Current Reporting

Device: Unmanaged

User: Unknown

Smart Shield Group: Guest / BYOD

Reported Policy: Baseline

This can imply that Baseline was the meaningful filtering context simply because no user identity was matched.

Preferred Reporting

Device: Unmanaged

User: Unknown

Smart Shield Group: Guest / BYOD

Applied / Reported Policy: Guest / BYOD Policy

This provides administrators with the policy context actually associated with the Smart Shield configuration.

Reporting Transparency

Where the policy shown is determined by fallback logic rather than direct user assignment, the interface should make that clear.

For example:

Policy Source: Smart Shield Group

or

Policy Source: District Default

This would help administrators understand why a particular policy is being displayed.

Requested Outcome

Ensure that Web Activity reports the most accurate available policy context for unmanaged devices.

The desired behavior is:

Use the policy associated with the Smart Shield context when no user-specific policy is available

rather than:

Default to the district root policy whenever the user cannot be identified.

Acceptance Criteria

This request would be considered addressed when:

Web Activity identifies the policy associated with the Smart Shield group for unmanaged traffic where applicable.

The district root/default policy is used only when no more specific policy context is available.

Reporting clearly identifies the source of the policy attribution where practical.

Administrators can distinguish user-based policy attribution from Smart Shield-based attribution.

Exported Web Activity data preserves the same accurate policy information.

The policy shown in reporting accurately reflects the configuration context used to filter the request.

Business Value

This enhancement would:

improve Web Activity accuracy;

reduce troubleshooting ambiguity;

improve Smart Shield validation;

provide more reliable policy reporting for unmanaged devices;

reduce false assumptions during support investigations;

improve consistency between configuration and reporting.

The requested principle is straightforward:

If Lightspeed knows which Smart Shield group handled the request, reporting should use that policy context instead of presenting a less-specific default policy.