Experience.FellowshipOne.com

When we are working with F1 support we are often asked to provide a usename and password so they can troubleshoot the issue. We have a user leftover from our install that has full rights to the database. We usually provide this login to the support technician so they can run tests on our database. Recently I've become uncomfortable with providing this since case notes are emailed and email is not secure. I would propose that F1 have a back door into all of our application instances so we do not have to frequently email passwords back and forth and so the investigation does not have to wait on the person who opened the tech support case.

Michael,

  You may want to send this up at the Ideas site to get votes for the suggestion. That's the best way to get visibility on requests. Ideas with lots of votes get quite a bit of attention on our side.  (That's not to imply that the others don't get any, but if we see a lot of points for a particular suggestion, that's a good indicator that it's important. :) )

  In the meantime, I'd suggest disabling the login and changing the password as needed. You could do this for each ticket or you could create a more limited account just for F1Support.  I know that several of our customers do that.

  I definitely appreciate and understand your concerns in this area.

-Peter Schott

The issue that Michael presented is something that bothered me also. I noticed it in our monthly support log report and immediately discussed the issue with Lance Dacy (Director Customer Services at Fellowship Tech). If I recall, he mentioned that being able to log in as the user with their user id is sometimes necessary to see exactly what the user is seeing. (For example if the problem is security rights related, they would be able to see that when accessing F1 under the user's id where they would not be able to see it using a general purpose support id.) Unless Fellowship Tech support moves to some sort of web based support tool (like Bomgar, Help Desk, LogMeIn) where they can support the user by viewing their screen; I don't see any easy solution to the need to ask the user for their id. (Obviously a programming change to the system allowing a F1 support id to run a session with the implied rights of a specific user would work - but that would need to go through product development cycle.)

Anyway, the main reason for my reply is that your post made me think about the problem and a possible easy solution. To me the easy and immediate solution is for the F1 support tech to continue to document that they are logging into the system with the individual's user id, but to no long record in the support log the user's password. This seems like a very simple solution to better address the security concern that both you and I share.

Lance can you jump in and comment?

---

John Schneider
Forest Hill Church

Thank you all for your comments. Since my joining the customer services team back in late 2006, I often thought that one of our challenges was to troubleshoot user’s issues within a test database. There are simply too many variables that affect an issue and we know it is now best to troubleshoot a user’s issue as that user. In addition, we stand by our policy that the data residing in the database is the church’s. We do not provide anyone on staff a “backdoor” to view the application and its resources as that user. Each instance requires an existing user account for anyone on staff to log in to the church’s database.

The next challenge was based on how to capture this information. We usually tell our users they can either have their Administrator create a new account for our support team that has the same rights as the user or we can simply sign in as that user provided we know their log in and password. The user can simply change their password when we are done testing their issue or they can disable the log in if it was created specifically for support.

We now currently use WebEx which allows us to share desktops between clients as well as allows us to control a client’s desktop. This is a great solution when all schedules present themselves in a fashion that allow both the user and support agent to join the session at the same time. There are other times when the schedules don’t align and we are actually escalating the incident to another team member. That is when it is valuable to have the log in information so that we can troubleshoot at anytime as that user without interrupting their schedule.

Our support tool (the tool which we track all inbound incidents) is an encrypted site and cannot be logged into without PTA (Pass Through Authentication) by the API. I do understand the concerns about having this information appear in emails or any other medium, but we normally do not include all pieces required in the incidents. You must have a user name, password, AND church code to successfully log in to Fellowship One.

I appreciate all the comments on this thread and I continue to work on a solution that would allow your users to grant support access to their account for some duration and then can be shut off at will by that user. I have met with our Development Team several times to ensure an elegant solution is chosen and implemented. In the future, we will be able to provide such technology that allows for secure transactions by the user and allows our Support Team to troubleshoot the exact issue via a real time user’s account. Please let me know if you have any further questions.

God Bless,

Lance

---

Lance Dacy
Director | Customer Services
Fellowship Technologies

Lance,

Thanks for your comments.

I wanted to post this reply to correct my earlier comments. The user id and password that are entered in the support log are entered by our users, not the Fellowship Tech Support Representative. The representative asks for the information from the end user and then the end user types it into the support ticket in response - for use by the representative. Sorry about the confusion in my comment above. I think we all agree that is not the best long term solution, but it might be the best option available to us at this time.

Also, I wanted to thank you for hard work in trying to make the support process a better one. I know there are some very good ideas floating around as to how to improve the whole support process and most of the good ones will take time to implement. We will continue to communicate our concerns and ideas to you - and we will look forward to the future when some of those improvements are implemented.

---

John Schneider
Forest Hill Church