Sections in this category

Just Who "Exactly" Modified The Record? Services and Admin Users in RAMCO

The Different Users in RAMCO

There are 4 different users in the RAMCO system that could make automatic changes to records.  Often Times we have seen in support tickets confusion around who exactly is modifying the record?" That confusion on who touched the record can turn into frustration when it comes to attempting to follow the paper trail. Many times during this paper trail members of staff will run into one of these users. We want to establish a baseline on who these users are and what changes they can possibly make. 

 

For context, an example of this is often we see changes made to the member subclass field on the membership record itself. You can see in the screenshot below, that the "changed by" is "Services High Performance." The easy answer is that these changes are coming from down from M1/NRDS as a result of a trigger. The trigger could be a host of things but the important thing to take note of in this situation is the "Changed By" Field on the Audit History. We will dive deeper into who and what exactly is this services user and the changes they can possibly make in the system.



Please see the screenshot above. The change was made on a membership record immediately after a change was done by a member of staff. this is important context to understand that this change came from NRDS/M1.

The User "Administrator_____ CRM"

In the past, RAMCO has used this one user as an identifier  for any Modification made by the support team, NRDs/M1, or members on the portal. Which as you can tell can get very confusing as there was no real way to differentiate where the modifications were coming from. A change on the portal by a member could easily be mistaken for a change by the support team and vice versa. This user will soon be deprecated in the near future. It is extremely rare to see this in your system in recent times. Nowadays we have broken down this user into different users in order to make it easier to track modifications to records and where they come from. 

Administrator Pod __,

In breaking down the above user into different users RAMCO has created this user to identify any changes made by the support team. This could be in the form of a workflow or a direct change made by RAMCO's support team to a record. It's important to take note that the Pod number of this user will change based on your organization. 

NOTE: Some organizations will have their own VM and have this user defined as Administrator, (Name of your organization)



Service Pod x/ Services High Performance

This one could be a bit tricky. As it could be result of many different circumstances. It's important to take note of the context of the situation when attempting to follow a paper trail that involves one of these users.


The first thing to take note of is only Organizations that require their own personal VM will have the user Services- High Performance in their system. Other organizations will see this as, "Service Pod ___."

 Both of these users will capture any changes made by at least the following:


1.Any changes on the member portal done by the member themselves

2.Any changes that have come down from NRDS/M1 

3.Any changes done by Staff members through the ISV Wizards. This can be the Membership Application Wizard for example or even the Process Payment Wizard.


The context of this situation will allow our support team to be able to track where these changes are coming from. This is why it is important to provide as much detail as possible when submitting support tickets regarding these users. 





User API

Some organizations will use Third-Party applications to meet their business needs in areas like email marketing. An example of this is ClickDimensions or even Aristotle. These applications will require communication to RAMCO that sometimes involves modifying a record. These changes will be identified by the user API.

System

This user reflects a lot of the system at work. Often times when Staff saves a record you will see other fields populate automatically, such as when saving a brand new order record. These are registered as plug-ins that fire and take action on records when a trigger such as in this case (Saving the record) is commenced. 


Was this article helpful?

0 out of 0 found this helpful