Settings and activity
25 results found
-
2 votes
Michael Wiley
shared this idea
·
-
23 votesMichael Wiley
supported this idea
·
An error occurred while saving the comment -
36 votes
An error occurred while saving the comment Michael Wiley
commented
Not sure if this is exactly the right idea to add on to, but having an audit trail that an action was taken by someone proxying in as someone else appears to be critical for a variety of control functions. As the system currently functions, anyone with the permission to login as someone else can login as other staff (who are not in the Admin group) and perform functions that might be outside of their security group. For example, our Philanthropy team who reasonably should be able to proxy in as a donor to assist them also has the ability to login as a member of our finance team and generate checks. Without another form of control in place to prevent that, it is absolutely critical that logs should record the actual person generating payments of any kind, especially if they have used the Login As function to impersonate another staff member.
Michael Wiley
supported this idea
·
-
14 votesProposed Idea · 2 comments · CommunitySuite Idea Lab » Donations/Pledges/Promises/Public Securities · Admin →Michael Wiley
supported this idea
·
-
71 votesMichael Wiley
supported this idea
·
-
86 votesUnder Consideration · 12 comments · CommunitySuite Idea Lab » Grants, Grantees, Grant Types · Admin →Michael Wiley
supported this idea
·
-
32 votesProposed Idea · 0 comments · CommunitySuite Idea Lab » Donations/Pledges/Promises/Public Securities · Admin →Michael Wiley
supported this idea
·
-
10 votesProposed Idea · 2 comments · CommunitySuite Idea Lab » Donations/Pledges/Promises/Public Securities · Admin →Michael Wiley
supported this idea
·
-
9 votesMichael Wiley
supported this idea
·
An error occurred while saving the comment Michael Wiley
commented
We have noticed this as well. Very strange to have the only merge field available to sign a communication to be formatted with Last Name first. Our planned approach to get around this is to omit the {{employee_name}} merge field altogether and sign the email generically. It is unfortunate that the merge field that could personalize communication is unusable.
-
10 votesMichael Wiley
supported this idea
·
-
8 votesMichael Wiley
supported this idea
·
-
36 votesMichael Wiley
supported this idea
·
-
19 votesMichael Wiley
supported this idea
·
-
12 votesMichael Wiley
shared this idea
·
-
2 votesMichael Wiley
shared this idea
·
-
9 votesMichael Wiley
supported this idea
·
-
9 votesMichael Wiley
supported this idea
·
-
9 votesProposed Idea · 2 comments · CommunitySuite Idea Lab » Templates (excludes Fund Statements) · Admin →Michael Wiley
shared this idea
·
-
6 votesMichael Wiley
shared this idea
·
An error occurred while saving the comment Michael Wiley
commented
Here are screenshots of the Page Count merge field values from the online and paper versions of the same fund's statement, both generated as part of a single batch of statements.
-
23 votesMichael Wiley
supported this idea
·
I also added this comment to the other suggestion that included a View Only access. Having an audit trail that an action was taken by someone proxying in as someone else appears to be critical for a variety of control functions. As the system currently functions, anyone with the permission to login as someone else can login as other Users (at least those who are not in the Admin group) and perform functions that might be outside of their security group. For example, our Philanthropy team who reasonably should be able to proxy in as a donor to assist them also has the ability to login as a member of our finance team and generate checks. Without another form of control in place to prevent that, it is absolutely critical that logs should record the actual person generating payments of any kind, especially if they have used the Login As function to impersonate another staff member.