Applying custom variables to existing catalog entries / notifications

[epaul020]

at first glance, I thought using custom variables would be a great way to solve my issue.

I was looking to add custom variables into the standard notifications for items that may change in the future.  For example, our help desk phone #

I created a CustomVariable (Catalog Mgmt>Admin>Custom Variables)  "Custom_TACNumber" and defined the value with our existing help desk phone #

I added the ##Custom_TACNumber## to the "Software / General Catalog Item Request Order" so that the # would be included in future notifications....didn't work 😞

I found some documentation online that says the variables only apply to new catalog entries (unless you edit the existing catalog entry directly).

I added the variable to Catalog Template "Freeware"... everything worked as planned  🙂

Here's the issue...

Now I went to change the value of that variable ...where do I edit it ?   If I edit the "Freeware" Catalog template, that will only apply to new entries, correct ?

Is there something that I can edit to apply to ALL catalog entries when the "Software / General Catalog Item Request Order" notification is sent ?  (only using that Notification as an example.)

I tried using the Catalog Management > Administration>Custom Variables item...no luck there either.

HelpNet documentation guides are vague in providing examples

thanks.

Using AppPortal 2019 R1

[jdempsey]

As you've noted, custom variables that are defined at the global catalog level (https://helpnet.flexerasoftware.com/appportal2019r1/default.htm#helplibrary/APRCustomVars.htm) behave just like catalog item templates.  Any new catalog items that are created after that global custom variable has been defined will inherit a COPY of that variable (not a link to it).  If you change that global variable later, it will not change the value assigned to individual catalog items that have previously inherited that variable.  This behavior holds true with variables that are defined within a template as well.  If you create a new catalog item from a template, any custom variables in that template will be COPIED to the new catalog items (again, not a pointer reference).  Unfortunately, if you ever need to bulk update the value of that custom variable at a later time, the only way to do that (without going through the UI one by one) is to run a SQL update statement directly against the database.

That said, I guess I'm not clear what you were hoping to gain by using custom variables in the scenario you describe.  Couldn't you simply update the global notification templates if the phone number changes?  It seems there would be way fewer email templates to update than there would be catalog items.  Or do you modify a lot of the email notification templates at the catalog item level?

[epaul020]

my thought was to create a corporate standard format for all the different notification types which includes (approvals, denials, reminders, success, failures, etc..) and include the variable in those notification templates so if/when the content changes, we would be good to go.

I guess I don't really understand the purpose of the Custom Templates then if they are not used to update custom content "on the fly"

We're just starting out with AppPortal, so we really haven't implemented a concrete policy yet...but I know for sure using the custom templates at the catalog level would be a nightmare (unless it was something specific to that app only).  We expect to have over 400 apps available when we go to production.

[jdempsey]

I see.  So basically you have some content that goes into all of the different notifications and you'd like to be able to update those things just once instead of on every notification template individually.  Makes sense.  Seems like a great enhancement request.

The custom variables are intended to be used on individual catalog items to define things that are catalog item-specific.  For example, you might define an application owner for each application in your catalog, and that could be different for each application.  Then you might want to include the name of that application owner in some of your email notifications or perhaps assign a ticket in your ITSM system to that application owner when a request is submitted for that application.  You can do all of that by defining a custom variable (e.g. Custom_AppOwner) and assigning a unique value to that variable on each catalog item.  If the bulk of your catalog items will have a common value, but some will be unique, you could define that "default" value for the variable at the global level and then change the value on the individual catalog items that are different.  But in the email notifications or the ITSM operations (or wherever else you choose to use it), you would still reference the single variable ##Custom_AppOwner##.  Basically, we use custom variables to store values for attributes that aren't included in the catalog item properties by default.  Another example is if you're using App Broker for ServiceNow, you could use custom variables to specify the workflow that should be applied in ServiceNow if using different workflows for different items.

I definitely agree that there are some good use cases for having global custom variables that are truly global and just referenced instead of being copied to catalog items.  In fact, I initially thought that's how it worked as well until I tried them out and discovered otherwise.  But there are certainly plenty of use cases for them the way they are currently implemented.

As for custom email templates, any changes you make to the global notification templates will take effect immediately for every catalog item in your catalog unless you have catalog-item-specific templates defined (I agree that managing these on every catalog item would be a nightmare, so we use those sparingly).  There is definitely value in standardizing the templates and applying your corporate branding.  It's just that if you change some portion of those customizations (like a phone number or a logo image file), you would need to change that on each global template that uses those values.