Feature - Automated Account Reviews (end of April)

I’m beginning to tinker with the beta and a few questions have come up. Are all the Pulls stored in the eramba database going forward? If so, should we anticipate growth in storage needs?

Also, Is it possible (since I’m testing) to clear out data and start fresh?

Hello there!

yes they are, we tested this with million rows of data … performance wise is not an issue and even a million rows of data is not really more than 100-200 Mb of database. We should be ok, but as you well said needs to be monitored for a few months.

When you delete an account review, it all goes to “trash” which actually is not deleted just “trashed” (there is no way to clean the trash and that has been done on purpose as deleting data permanently is not something we want to do)

1 Like

Continuing my tinkering efforts, we’re looking at running jobs on our standard job server separate from eramba to collect the feed files, but we’re having difficulty accessing the location of the feed files from the pulls.

Does the pull location have to be on the eramba server? Is it a relative path? If the path is on a different server, do we need to authenticate or map a location at the server level first?

adding to my original post…

  • If I delete a pull, but forget to first Stop the cron job, does that cause any lingering issues, or with the cron fix itself? (Yea, I did that)
  • If the owner, for some reason, changes the OK/Not OK status of a submitted feedback, there does not seem to be any flag indicating incomplete results (except the counts won’t add up). Should there be a flag or indicator?

Continuing to explore. Does anyone have suggestions on dealing with systems that use different user IDs?

For instance, depending on the system people may log in with their LastNameFirstInitial, their email address, or some other unique identifier. When comparing to a list of active employees what’s the best way to handle these different user IDs from different systems? Should I have an Active Employee list that has the same individual listed in multiple records, but using different user IDs for each one, to catch all the variations?

e.g.
SmithJ
john.smith@company.com
jsmith80

What other strategies do others use?

I got that question and to be honest i dont have that problem … our AD guys did pretty much every possible mistake when they did the architecture of our AD with the exception of using standard accounts everywhere.

Yea, AD related access controls (via groups) should be fine it’s the web-based accounts, which may not be tied to SSO for instance, that I’m more concerned about. Just wondering if anyone else on the forum has wisdom to share. :slight_smile: