Use Notification Patterns to personalize Learning Alerts

Oracle Learning centralizes learner notifications through Alerts Composer. This provides consistent governance, but it can create challenges for organizations migrating from an LMS where administrators control notifications separately for each learning activity.

The Notification Pattern attribute in the Redwood Learning Catalog can help bridge this gap. It provides a classification value that can be assigned to a learning item and referenced in alert conditions to determine which notification content should be sent — or whether a notification should be suppressed.

What Is a Notification Pattern?

Notification Pattern is an attribute available on supported Oracle Learning catalog items. It can be used to trigger, disable, or customize Resource and Event Learning Alerts ( triggers can not be modified for Event Learning Alerts)

A filter criterion for a resource-based learning alert, can use the selected value to determine whether the alert should be generated.

Similarly, Notification Pattern can used to customize notification body for resource or event based learning alerts.

The attribute that can be used here is “${learningItemNotificationPattern}”. You can join multiple Notification Pattern values by AND/ OR condition. This attribute is part of the resource “learnerLearningRecords”.

Notification Pattern values then need to be mapped to the appropriate Learning content on the learning catalog page.

A Practical Implementation Use Case

I recently worked with a manufacturing organization migrating from a legacy system to Oracle Learning. In the legacy system, learning items are compartmentalized into multiple domains. Learning administrators can enable, disable, and customize notifications at the individual activity level. Some domain examples are as follows

• Third-party providers
• E-commerce
• Domestic operations
• Canada
• Mexico
• Restricted learning

The client also uses tracking-only activities. For these actitives, Learners don’t register for these activities directly. Administrators record the participation or completion after the training occurs. For these tracking-only activities, the client doesn’t want Oracle to send a standard completion notification. For other programs, the notification must contain program-specific instructions.

Because Oracle Learning alerts are centrally administered, setting up every legacy notification as a separate Oracle alert would create a large number of templates and increase ongoing maintenance.

We used Notification Patterns to create a more scalable design.

Designing the Notification Pattern Values

We aligned the Notification Pattern values with the client’s domain structure.

For example if in the Current Domain or Business Grouping like Domestic Operations should generate specific notifications that include customized content.

This provided a familiar crosswalk between the current LMS structure and the future Oracle design.

However, the Notification Pattern should not automatically replicate every source-system Domain. The values should represent meaningful differences in notification behavior. If two Domains receive the same notification, they may not need separate patterns.

This creates an opportunity to standardize notifications during the migration instead of recreating every historical variation.

Suppressing Notifications for Tracking-Only Learning

We created a value called No Notification for learning items that shouldn’t generate the applicable learner alert.

We can include a condition such as :

Notification Pattern is not equal to "No Notification"

The alert is generated only when the learning item doesn’t use the No Notification pattern.

This approach can support tracking-only activities where administrators record completion but the organization doesn’t want Oracle to send the standard completion message.

Supporting Domain-Specific Notifications

When notification wording varies by business domain, the Notification Pattern can be used to select the appropriate template or conditional content.

For example:

Notification Pattern = "Canada"

The corresponding notification can include Canada-specific contacts, policies or instructions.

For a parent Domain that covers multiple second-level Domains, the condition can include the relevant values:

Notification Pattern = "Domestic"
OR Notification Pattern = "Canada"
OR Notification Pattern = "Mexico"

If a notification applies to every learning item, there is no need to include Notification Pattern in the condition. Unnecessary conditions make the alert harder to maintain.

Handling Program-Specific Content

Not every variation is domain-based. Some notifications include instructions for a particular training program.

For these cases, we use both:

• Notification Pattern for the broader business grouping
• Learning Item Number for the specific learning item

A conceptual condition might be:

Notification Pattern = "Domestic"
AND Learning Item Number = "LEARNING_ITEM_NUMBER"

The Learning Item Number is generally a better identifier than the title because titles can be translated or changed. The number should be unique and governed as part of the catalog design.

Get Ritwick Chatterjee’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Where multiple learning items use identical notification wording, the condition can group their numbers:

Notification Pattern = "Domestic"
AND (
    Learning Item Number = "ITEM_001"
    OR Learning Item Number = "ITEM_002"
    OR Learning Item Number = "ITEM_003"
)

This allows one standardized notification to support several learning items instead of maintaining duplicate templates.

Validate the Alert Resource Before Configuration

A field available on a Redwood Learning Catalog page or REST resource isn’t automatically available in every Alerts Composer resource.

Before building an alert condition, validate that the specific alert exposes:

• Notification Pattern
• Learning Item Number
• Learning Item Title
• Learning Item Type
• Assignment status
• Learner and recipient information
• Any other attributes referenced by the condition or message body

The available attributes can vary by alert event. A learning-assignment alert may expose a different resource structure from an Event, waitlist or approval alert.

The design should therefore be treated as an alert-by-alert mapping exercise, not as one condition that will automatically work across every Oracle Learning notification.

Recommended Governance Model

A controlled governance process is essential because the Notification Pattern becomes part of the learning-item setup.

Learning catalog administrators

• Select the appropriate Notification Pattern when creating or updating learning.
• Use No Notification only for approved scenarios.
• Avoid creating new values without governance approval.

Learning notification administrators

• Maintain Alerts Composer conditions and templates.
• Confirm that the required attributes are available for each alert.
• Test assignment, reminder, completion, withdrawal and renewal scenarios independently.

Business and program owners

• Approve standardized notification wording.
• Identify genuine legal, geographic or program-specific differences.
• Periodically confirm whether specialized notifications are still required.

Key Design Principles

The following principles helped keep the solution maintainable:

1. Use Notification Pattern only when notification behavior genuinely differs.
2. Don’t create a separate notification for every learning item.
3. Use Learning Item Number for program-specific logic.
4. Consolidate learning items that use identical notification content.
5. Use No Notification only with an explicit exclusion condition.
6. Don’t add a Notification Pattern condition when the alert applies to all learning.
7. Validate every attribute against the applicable Alerts Composer resource.
8. Test each alert event separately before deployment.
9. Document the owner and business purpose of every custom notification.
10. Periodically retire obsolete templates and conditions.

Final Takeaway

Notification Pattern provides a practical way to support domain-specific, program-specific, and notification-suppression requirements.

While doing that, organizations should look at the all notifications requirments holistically so that they can consolidate duplicate messages, standardize wording and establish clearer ownership for future maintenance.