14 Replies Latest reply on Dec 13, 2012 7:44 AM by byrona

    Using a Macro for email alerts in Advanced Alert Manager

    byrona

      So, I recently (yesterday) stumbled upon the fact that when I setup an advanced alert using Email as the Trigger Action I can use a Macro in the To section of the email. 

      What this will allow me to do is create a custom property for my nodes called "Primary Contact" and put an email address in that field.  Then I when I setup alerts instead of using a specific email address I can just use "${Node.PrimaryContact}" so that when the alert is triggered it will send an email alert to whom ever is listed in the "Primary Contact" field on the node.

      This is where my question comes in...

      What will happen if an email tries to send but there is no data in the "Primary Contact" field?  I am concerned that this might break something so I wanted verification that this won't cause a problem.

      Thanks in advance for any help on this!

        • Re: Using a Macro for email alerts in Advanced Alert Manager
          jainsworth

          Thanks for stumbling on this!  I had no idea it was that easy, now I can re-configure all my alerts. 

          During my testing, I found that not having an email address in the Primary Contact field didn't appear to break anything, just didn't send the email.

          1 of 1 people found this helpful
            • Re: Using a Macro for email alerts in Advanced Alert Manager
              byrona

              Glad I was able to help.  Thanks for your response it's good to hear that this doesn't seem to break anything.

              I am thinking that this could be pretty useful going forward.

              • Re: Using a Macro for email alerts in Advanced Alert Manager
                viol8tor

                Actually you can have a blank field and 1 separator like ; or ,

                 

                I posted a similar  hint -- Alert Trigger Suppression vs Alert Suppression.

                 

                You can combine multiple custom fields to compose another custom field.

                Custom field: Alert_Email   contains ${Node.MailTo1};${Nodes.MailTo2}  <--- ${Node.Alert_Email} goes in the To: field of Alert.

                Custom field: MailTo1    <--- auto populated

                Custom field: MailTo2    <--- exposed on the customer dashboard so they can update themselves.

                 

                There's definitely a lot of creative things you can do to simplify your life.

                 

                - v

                  • Re: Using a Macro for email alerts in Advanced Alert Manager
                    byrona

                    viol8tor

                    Thanks for this additional info.

                    How do you hide some fields while allowing your customers access to modify other fields?  This is something I might like to do if I knew how.

                      • Re: Using a Macro for email alerts in Advanced Alert Manager
                        viol8tor

                        In the device / node view you have assigned to your client, add "Edit Custom Node Property" from Miscellaneous - Miscellaneous Resources.

                        Once added, go back to the device / node view and Edit and assign the specify the custom property field you want them to have access to.

                        Repeat for each Custom Property you wish for them to have access to.  Users can update these fields without Admin rights.

                         

                        On devices that have a lot of custom properties (20 or more), I create a separate view just for the Custom Properties and link it to their node page via "User Links".

                        In the custom URL of "User Links" resource, add the following code: /Orion/NetPerfMon/NodeDetails.aspx?viewid=XXX&netobject=N:${NodeID}

                         - Where XXX is the ViewID number of the view that contains the a list of custom properties they can edit.

                         

                        For Administrators (that do not have SW Admin rights), I create a report that I turn into a "Web Resource" which will also launch a special view that will allow them to edit their custom properties.

                        (This is useful for updating Site information, like Addresses, phone numbers, etc.  The report is an easy way to list relevant data without having to drill down through each node.)

                        - When creating the report in Report Writer, make sure to add the "Status Icon" as one of the fields. (The nodeid should be there by default, if not add it and hide it.)

                        To the "Status Icon", in the Field Formatting Tab, add the following code to the Web URL /Orion/View.aspx?ViewID=XXX&NetObject=N:${NodeID}

                         - Where XXX is the ViewID number of the view that contains the a list of custom properties they can edit.

                        When viewing the report on the website, the users can click on the "Status Icon" which will send them to a different view which will allow them to update the custom property records.

                         

                        This is all good for simple 1 off changes.  For anything else, I still prefer to do it directly in SQL.

                         

                        -v

                  • Re: Using a Macro for email alerts in Advanced Alert Manager
                    d09h

                    I ran into this issue Friday.  I couldn't add any more email recipients in my alert.  I hated all the efforts going in to each individual alert with the same recipients.  There seemed to be a limitation of around 230 characters for the To: and Cc: and Bcc: fields.  I ended up creating three custom properties of that size and assigning them to the interfaces I was alerting on.  Where I used to make changes in four alerts (and four resets), I now only have to add the email address on the end of a custom property.  It's a little easier to validate that I can't fit any more email addresses when dealing with a custom property.

                     

                    Why not handle this via DNS?  Controlled by someone else and too much grief to coordinate those efforts.  Also well worth the flexibility gained.