Best Practices for an "Archer Support Team"
I wanted to discuss with you what best practices to implement regarding Archer support in production environment.
For sure, sysadmin role is to be avoided for L1/L2 support - only for L3 and install/config activities.
But so far, due to lack of time, we did use sysadmin role for support purposes in Prod ... and we want to get rid of that ASAP!
For our next quarterly release, we intend to implement a dedicated Archer Support Team Group and Role.
We intend to give create/read/update access to Content Records of all used applications and questionnaires in the Role Accesses Rights (for data import, we have dedicated roles, see Data Import Strategy for Admins for more). We didn't intend to add any additional administrator right.
On each used application and questionnaire, we'll configure a dedicated ARP that provide Read/Update access to the Archer Support Team Group (either by setting no rule, but putting the group into the Default Users/Groups with Read/Update rights).
One additional tool we configured into every application and questionnaire to help debugging DDEs is following:
- Define a text box for each (active) DDE that is implemented in the application; name and description are a copy of the DDE name, visible in both edit and view mode. Position the text box on a dedicated Archer Support Team tab for that application.
- Add (if not already existing) an "Always True" DDE rule and include an action to hide all these “DDE” text boxes; apply this action to “Everyone”.
- In each of the other active DDE rules, include an ACL action to DISPLAY the text box with the same name as the DDE rule; apply this action to the Archer Support Team Group only (this will hide these debug fields to all other end users).
As an example, here's a given application configuration showing all configured DDE text boxes:
Then, on a particular record, you easily get which DDE are active at a particular moment in time:
In that example, the Archer Support Team can quickly identify the only 2 DDE that are active for that record at that time. It may often be very helpful to solve L2/L3 issues or identify configuration bugs...
That's the way we are going to implement our Archer Support Team strategy for Prod.
Has any one else best practices to share? Would you recommend to add any other administrator right to such a L1/L2 support group?
I would be very happy to learn more about how you implemented Archer Support in your own environment!#
- archer admin
- best practices in securing archer deployment
- Community Thread
- engage support
- Forum Thread
- RSA Archer
- RSA Archer Suite
- support ticket
- tech support
I have some additional thoughts on Production Support of Archer that I will share a little later, but wanted to let you know that it appears you've essentially duplicated the functionality of the DDE Analyzer that exists within the platform today. I wanted to let you know this, because adding so many extra fields and DDEs to your applications can make them unnecessarily slow. Very cool way of doing troubleshooting that you've built!
If you do a Ctrl+Alt+Left-Click anywhere on a record in edit mode, you'll get the Analyzer to pop up. Once enabled, make a change to the record and see the list of DDEs and details about them.
Thank you for that, Scott Hagemeyer!
We of course used the native DDE troubleshooter in the past, but sorted out that, being a very handy tool, it nevertheless presents some limitations.
First, you only can see things once the record is already displayed (some DDE may have already been executed). As a consequence, what happened "before" the record is displayed (or let's say, identify why the record displays what it displays when you first open it) cannot be captured by the Event Analyzer: in this case, you have no way to debug your DDEs. The Event Analyzer only captures DDEs that are fired by changes after you already opened a record and had a chance to do that Ctrl+Alt+Left-Click. And these changes will not exactly reflect the DDE state at record opening (not really clear, but hope you see my point).
Secondly, I noted that some DDE (I unfortunately can't remember an exact example here - if I do, I'll update this comment) will have the effect to "reload" the page (or refresh the page), which will automatically close your Event Analyzer window...
Finally, as you mentioned, the Event Analyzer can only be used in Edit mode and if you change something on the record. It might most of the time be enough, except if you don't have the rights to modify the record... for instance if one of your DDE "locks" the record (for example when you set the status to Closed) and prevents you from doing any modification: the Event Analyzer will never display any DDE execution...
So, for these 3 cases, our troubleshooting method works always! Therefore, I wouldn't agree on the fact that we "duplicated" the native tool...
So far, we haven't seen any performances issue; but I'll carefully keep that in mind! Thanks!