redbug2 said:

$IF(Platform, M8)

I'm not familiar with that syntax for the "$IF" tag.  Which version of SBM is that? Can you point me to a user guide??

https://docs.microfocus.com/doc/Solutions_Business_Manager/12.1/ttwa_notification_tags   We are on version 12.1. This is the first time I've attempted the if.

What are the "Platform" and "M8" values??  The "$IF()" tag has a specific set of things it can do.  AFAIK, comparing Fields and values is not one of them, except for the ITEMTYPE field.

Thank you for your help. The platform field has values of "M5" or "M8". Its just a random single selection field. Ok, if your saying it will only work with ITEMTYPE I can live with that. I attempted the same exercise with ITEMTYPE field however I'm confused. Is the "ITEMTYPE" field now "ISSUETYPE"? Do I use the database field name or the Field name? Do I have to rename ISSUETYPE to ITEMTYPE? Or just create an "ITEMTYPE" field? Or, should I use the Field Name or the Database Field name? I've tried both ISSUETYPE database name and the  Item Type field name, both failed to trigger the IF logic.

My issuetype its named ISSUETYPE in my project.

Here's my new test code:

The ISSUETYPE is: $FIELDVALUE(ISSUETYPE)

$IF(ISSUETYPE, Oracle)

   This is an Oracle issuetype.

$ELSE()

  This is not an Oracle Issue Type.

$ENDIF()

*****************************************************************************************************

Results:

The ISSUETYPE is: Oracle

This is not an Oracle ISSUETYPE.

*****************************************************************************************

Yes, "ITEMTYPE" is the TS_ISSUETYPE aka "Item Type" field.  That particular incantation of the "$IF()" might require "ITEMTYPE". Confusing, huh?

For the notification tags, copy anything in UPPERCASE as-is in the docs.  Lower case params represent data or field names from the associated table.

$IF(CANVIEW, fieldname)

$IF(ITEMTYPE, value or prefix from TS_ISSUETYPE aka "Item Type" field)

$IF(VIEWLINK)

I think you might need to move the "Platform is M5 or M8" tests and decision making to M5 and M8 specific Notifications & Notifications Rules, then for each Notifications create a template.  Like an "M5" template and an "M8" template.

Yes, we are doing the separate template solution now. It's a maintenance nightmare. It would be nice if I could have just one template with difference content fed out by if statements. We have over 100 message templates that are essentially the same content with only some content changing based on Item type. So, if we change the content on one we have to change it on over 100. .

Yes, we are doing the separate template solution now. It's a maintenance nightmare. It would be nice if I could have just one template with difference content fed out by if statements. We have over 100 message templates that are essentially the same content with only some content changing based on Item type. So, if we change the content on one we have to change it on over 100. .

I totally understand the nightmare as I've been there before. One thing I have done in the past to try and circumvent this is to use a text memo field within the app to hold extra "template data". This could be done plain-text or HTML. Then I use form-actions or scripting in Composer to set this field based on other field criteria. This can be a partial amount, or the entire template depending on your needs (also note a single memo field in SBM is limited to, including html markup, about 65000 characters).

For example, my template might look something like:

$BEGINSUBJECT()Really important notification $TTID() $ENDSUBJECT()
Attention, 
Item $TITLE() was edited by $FIELDVALUE(LASTMODIFER) and needs your review.

Here are some details:
$FIELDVALUE(SPECIAL_TEMPLATE_FIELD)

To view the item click $LINK(swc, here);

Then, in composer I would set the "SPECIAL_TEMPLATE_FIELD" to whatever was needed. When users edit an item the action/script would ensure this field is correct, and then when notification sends you can get the desired uniqueness. You just need to ensure that all users that could receive notification have access to view the field.

EDIT:

Another way to do this is to define Strings in the "String IDs" table (TS_STRINGIDENTIFIERS) that contain the content of the template, then reference those in the HTML template using the "$STRING()" template tag.

The contents of the String ID "Value" field is treated as HTML.  I didn't experiment to see if template tags contained within the body of the String value would be expanded.  That would be cool if it worked.

I tried using Application Variables and Form Localization Strings.  I was not able to find a Template Tag syntax that would work with either of those but, fortunately, the String IDs approach works.

My justification for this approach was trying to avoid putting all that HTML in the database for every single record.  We have several Apps with tens of millions of primary table records, so having kbytes of HTML text on every item would not make our database and infrastructure people happy.