Need some career advice, hopefully I am in right party
How can a contact center agent, from being CRM end user get into CRM consulting? I have theoretical knowledge of CRM implementation, job role of admin, support agent etc. Is there any specific skill that has to be mastered or there are lot of other things to go through than the existing skills.
enlightenment on this would be greatly appreciated.
You are in the wrong place, but I like your question and I have some suggestions.
As a CRM end user you have primarily been concerned with figuring out how to use a process within the system (customer support in your case). CRM consultants need to understand how that process was designed and the tools used to configured it.
A good first step would be to explore some of the tools within CRM. Understanding the Advanced Find is important for CRM consultants and will also give you more power as an end user. Use the advanced find to create personal views to enhance your user experience. Similarly creating personal workflows will enhance your configuration knowledge while potentially providing you with improvements to your user experience.
You will probably be limited in the system you use so I recommend you get access to a sandbox system to play around in. Microsoft provides access to free CRM online systems for exactly this purpose. Practice creating new entities, relationships, and fields of different types. Set up forms and views for your new entities. Create business rules, process flows and workflows to create a process around your new entities.
Taking an online class on CRM customization and configuration can be an easy way to get yourself started with consulting concepts.
Go apply for CRM consulting jobs. CRM consulting is a fairly niche industry and it is difficult for consulting firms to hire experienced CRM consultants. As someone who hires CRM consultants I am generally skeptical of end user experience, but if an end user shows knowledge and aptitude I am likely to hire them.
I've not only worked Tier 2 support for Salesforce but also have worked as a consultant. You need to not only understand business requirements, but implement them in the most efficient manner possible in Salesforce. Getting a job as a consultant typically requires at least a couple years experience as an admin, not an end user, an actual admin. It also typically requires certifications, At least the Administrator, Developer, Sales Cloud Consultant and Service Cloud Consultant certifications, and probably the Advanced Administrator as well. There are a lot of getting started info out there, Salesforce has done a great job. For instance, here is the Workbook
On top of that you need to have an understanding of different industries, for instance the financial industry or manufacturing industry, to understand their business processes. Working in a contact center you should look to gain a deeper understanding in how and why things work there.
As highlighted before, this is not the right place to ask this question as it is a place for more technically oriented questions. That being said, each and every one of us on this forum had to start somewhere, and often with far less experience that you have as a user.
If you're willing to accept an entry level position - and you fall within the age category - then your current experience is the cherry, but the cake will have to be about actual technical experience. Ie. IT engineering degree and/or proven participation in programming projects (open source or otherwise) and anything that may show that you have the foundation skills for an IT consultant.
As the company will be investing a lot and want's to have some certainty that it will have a return on it's investment.
In case you're looking for an above entry level position, then your new employer expects that you can be put to work right away without too much training. As highlighted by BattleCodez, experience with development processes, relevant application certificates and actual work experience are now must-haves. Based on your description, I don't think you have that.
As for a general career move you may want to opt for a Business Analyst role. This is a more Industry Process related role where the business processes are the expected experience. In your case how are calls handled, routed, and what does the client in your industry expect from as a customer. In this role you would be expected to have a deeper then average user understanding of what the tool CAN do, but not HOW that is created.
In this case become a key user, obtain functional admin privileges and move away from the actual calls, to an expertise based supporting role.
Related
I have gone through the documentations of Bonita and read a book about it. I have also watched almost all the tutorials offered by bonita on YouTube. However, the software limitations are not clear to me yet.
The company that I work for, a consultancy company, wants to use bonitasoft to manage its enterprise resources.
Examples of tasks that we want to implement :
Vacation planning for our employees (This a task so it is easy to
implement with Bonita)
Finance management and generating bills. (This is not a task. I need
to link a consultant to a contract and a client. Finally, generate a
bill at the end of each month)
Manage how bonuses are attributed to different consultants. This
depends on their performance. (Not a task)
Consultants should be able to see their history and how long they
worked for a given client and how much money they have brought in.
(Not a task)
Managing job applications. (Applications and uploaded files like C.Vs
and cover letters).
I was not able to find any demo website made by bonita to see if people tried to build an ERP system based on bonitasoft. Is this possible?
I think that it should be possible to create a form and modify it using JavaScript to implement a non-task functionality.
Is this considered as hack?
Are other people using bonita this way or not?
Also is implementing non-taskfunctionality possible using widgets (HTML, JAVASCRIPT and maybe an external webservice)?
Bonita BPM is a process-based application platform. I'm highlighting the process part of it here as this is a key concept in the platform.
Basically, the business logic part of any Bonita application is designed using a BPM (Business Process Management) approach. You design a process that represent your business logic and implement its behavior by coding business rules, data processing, integration with third-party systems and so on.
Then once, the business logic is implemented, you can build reports that will display to the end-user the data resulting from the execution of the different processes.
If we take the examples you gave:
Vacation planning for our employees (This a task so it is easy to implement with Bonita)
Typically handle by a process.
Finance management and generating bills. (This is not a task. I need to link a consultant to a contract and a client. Finally, generate a bill at the end of each month)
Can be handle by a process. The finance manager will have initiate the generation of a new bill from the application. But really, in the backend, it will trigger a new case (process instance), then follow all the steps down to the generation of the bill.
Manage how bonuses are attributed to different consultants. This depends on their performance. (Not a task)
You're right, not typically process based. Maybe just entering the bonuses value in a DB. If there are business rules associated to the calculation of the bonuses, it could be handled by a process.
Consultants should be able to see their history and how long they worked for a given client and how much money they have brought in. (Not a task)
Should be a report pulling data from an external DB or the Bonita DB.
Managing job applications. (Applications and uploaded files like C.Vs and cover letters).
Typically process-based.
So the short answer is yes, Bonita can be used to build this kind of application.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am trying to understand the licensing issues on I would come across on Force.com for developing an application that will have its own data source and will also be pulling data from SalesForce.com via api/service. I have spent over a day researching this from various sites but most of them keep throwing up new things which don't really answer my questions and have got me more confused. IF anyone here has any insight into this that can help me understand the cost of development and maintaining a site using Force.com, so I can compare it with building an application ground up on say .Net or Java and hosting it on a different cloud provider, then please help me out. My questions are:
If I have 5 developers working on an application called XYZ using the Force.com platform, how many Force.Com licenses would I need to purchase for such development work and of what type should those licenses be?
Would I also need to buy separate SalesForce licenses if those developers need to fetch data from the SalesForce database through code written on Force.com?
If I already have a SalesForce license then will my access to SalesForce be suspended if I convert that license to access Force.com for doing development work?
Can I reuse those same licenses for the testing phase later or should I buy separate licenses for testing?
Once development is complete and people create accounts for themselves on my XYZ web application, will they need a salesforce login to access the salesforce related data from their company network or can they still access it without?
If my XYZ web application doesn't access SalesForce's data then will my XYZ web application's users still need a salesforce or Force.com license to login into XYZ?
If I dont use Force.com as my development platform, and I still need to access SalesForce data, how many licenses would I need to have? One per login created on my XYZ application or just one will do?
Thanks.
You might be better off asking this at salesforce.stackexchange.com (beta). Seems like quite a lot of experts there have done some cool integrations, managed packages etc or even are ISVs. so they might have more experience in the matter. They'll maybe even point you to database.com.
Or just go and talk to SF sales rep.
Also I think you don't understand that you don't simply "buy a Salesforce license". You buy licenses bound to particular production organisation (an instance if you prefer). You can't transfer them between organisations and the fact that your web app will talk to specific Salesforce instance doesn't mean you can use same license too connect to different instance. So if this is what you mean by
I have spent over a day researching this from various sites but most
of them keep throwing up new things which don't really answer my
questions and have got me more confused.
then you'll have hard time...
I think for such question you'll need to eventually ask your lawyer, don't trust people on the internet :) Safe harbor, blah blah, don't sue me...
To kick off the development you don't have to pay anything. Sign up for Developer Edition and hack away. (each developer can do it, you can synchronize between them using SVN etc - it's definitely enough for quick start). If you already have a "production" (for example Enterprise Edition") then I think up to 4 simultaneous logins are allowed for each active user. This counts for different channels (so for example developer who would both click through app's UI and work in Eclipse IDE counts as 2) so you can try to do some cost cutting here... But I'd recommend 5 full Salesforce licenses.
No, will be sufficient.
I don't think you can convert licenses ;) You'd simply buy licenses of different type and contact them to reduce the count of licenses of type you don't need. You can kind of convert users by assigning them license of different type (and this might lead to change of Profile). As a result you for example downgrade a full System Administrator (on Salesforce license) to say user who can see only Chatter and loses access to Accounts etc.
You can use same licenses. Even to say deactivate developer user accounts and use the freed licenses to create some test users.
Depends how many features of SF you'd want to use (in terms of data ownership, visibility etc.). You will have to provide "some" credentials of an active user in your Salesforce. So you might be fine with having just 1 "integration user" account that would see all data and then do all filtering etc on your webapp.
I don't understand that one so I'm going to say "no" ;) If you don't need to connect to SF and get the data - don't? Unless you have some kind of Single Sign On solution there.
If you need to access Salesforce from external app you need to authenticate. Username + password, Oauth,sessionId, single-sign-on... whatever the means - SF needs something to say that this user is active, he can see this data. So it kind of goes back to answer #5.
I asked this over on Superuser and it was suggested I try this here:
Can anyone recommend a quality source to learn databases? I am changing careers and have no background in computers but this is what I have chosen to do now.
I was thinking of taking an intro course at a community college but I have no problem teaching myself with a book and some software. I am looking to accelerate my learning curve and don't want to spend an entire semester on an introductory course if there is something better out there.
Any suggestions are welcome. Thank you.
Edit:
Thank you for the feedback. The MS site and Oracle look promising.
I am pursuing a career in software development. I have taken C++ and C# at a community college and was accepted to a masters program for the spring. What level of database knowledge/implementation is required to program in C++ at the master's level and not get handed your lunch?
I guess I need to know how databases are used in programming. I don't have the common core of experience in order to explain the question more thoroughly without tangentially departing into illusory ideals of a programming career.
At any rate, what you have provided is enough to get me going and it will, I am sure, uncover further areas of interest.
Thank you kindly.
There's a whole lot of aspects of "learning databases":
administering databases
designing databases (modeling)
implementing databases (might require adding business logic into triggers and stored procedures).
using databases (and this might be 'writing a query' to aspects of data mining)
And then there's what type of database. Most people these days assume RDBMS, but there's the push towards NoSQL and tuples stores, etc.
There's no one good answer without a little more information about what you're trying to do.
In addition to what people here would consider as database-related jobs (DBA, database developer, data modelling analyst), there are a lot of semi-technical jobs around that refer to themselves as "database people". In particular, you get report analyst -- often using tools like Crystal Reports, Cognos, SSRS -- and business analysts who work on large customer databases, often defining more how the data should be used in various marketing activities than doing much coding. So it would be up to you to decide if you wish to have a more "business" aspect to your career goal, or to work in data entry/management, or do development and design, or to become a specialist admin certified in a particular vendor's software.
In all cases, however, given you start from scratch, some understanding in how relational database systems work would be beneficial. Someone mentioned Element K courses. Personally, I've found the SQL Zoo interactive online course particularly engaging, and have used it with new staff who had to get up to speed with SQL skills in a short time. Also, this tutorial looks well done. For self-study, I recommend the Head First book series, as in Head First SQL. All these recommendations are extremely SQL-centric, though.
Microsoft also offers tutorials that go with Access and SQL Server Express, but I'd warn not to become locked in. SQLite is a free and extremely lightweight RDBMS, which is perfect for trying things out, either using a programming language (if you know one -- if not, I recommend Python).
As for recommending a provider, you're not even saying which country you're in (though from mentioning "community college" I guess it's the US), what your budget and mobility are like etc, so it's hard to decide. Maybe a mentor or advisor at your community college could help?
The IEEE Computer Society has some online Element K database courses available for members. IEEE runs memberships by the calendar year. Professional membership dues are $50 for a half year and $99 for a full year of professional membership. Student memberships are $40 and $20 for full and half year, respectively. This might be less than the cost of one course.
ACM has some online database courses in their catalog also. They also use Element K, so it seems likely they are the same courses. A full membership is also $99 per year, student is $19 per year. (Their membership year starts when you join.)
I assume your goal is to get a job, since you mention you are changing careers.
I understand you wish to accelerate your learning curve. Make sure you do lots of hands-on work, then, to make sure you know how to do things and have skills in databases. The skills, as they say, pay the bills.
I don't know what your background in computer programming, computer science, or information science / managed information science is. If you have some background into those topics, you might be able to make it into the stuff I recommend below.
Most databases are relational in businesses. Depending on the business, they run different datbases. The two really big ones are Oracle and SQL Server.
I've known a couple of friends who learned databases (and other enterprise software) by going online and reading as much documentation as they could put their hands (mouse?) on the Oracle and SQL Server websites, and for other enterprise software. They went and applied for jobs, had enough business sense / charisma, could read/write American business English well, and were good enough to get the job with little/no experience, and have done very well. It pays their bills, and is a stepping stone to bigger things. You might be able to do the same. Go on the Oracle or Microsoft websites, and grab the documentation. Read as much of it as you can, circle words you don't know, try to find the definitions. Find a local guru (that's the main advantage of the community college, they have smart people with communication skills who can help), and talk with them.
If your a tremendous reader, you could do this in a month.
EDIT:
As to how much "database" knowledge you need to know to get into your master's...
It depends on the program; I'm going to assume your'e going for a professional program and not a academic one. Depending on the master's program, you may/may not need to know databases. Consult your professor or advisor to see if this is something you could tackle right away.
You need to know, ultimately, how to "talk" to a database. Think of this like trying to do business with folks in a foreign country:
You'll need to learn the language (relational databases use a language called SQL; make sure you know how to formulate a basic query (SELECT), and modify the data in the database (INSERT / UPDATE / DELETE)).
Make sure you know the culture (what is a table, what is a row, what is a column, what is a tuple, what are keys (foreign/primary/candidate/alternate/super), what are triggers, what are the normal forms, what is an ERD diagram, what is relational theory)
Make sure you have safe transportation (learn APIs to communicate with the database in C++ and C#. Learn how you can run SQL queries on the database from your app and get resulting data back inside your app. Perhaps learn about ORM tools and how to get/set data that way).
The above is what an intro course covers.
I'm part of a software development company where we do custom developed applications for our clients.
Our software uses MS SQL Server and we have encountered some customers which do not have a DBA on staff to manage the databases or if they do, they lack the necessary knowledge to perform their job adequately.
We are in the process of drafting a contract with one of those customers to provide development services for new functionality on our software during the next year, where they have an amount of hours available for customization of our software.
Now they want us to include also a quote for database administration services and the problem is that they are including a clause that says that those services will be provided only when they request it.
My first reaction is that db administration is an ongoing process and not something that they can call us once a month to come for a day or two. I'm talking about a central 1TB+ MSSql Cluster and 100 branch offices with MSSql Workgroup edition.
My question is for any suggestions on how I could argue that there must be a fixed amount of hours every month for dba work and not only when their management thinks they need it (which I’m guessing would only be when they have a problem).
PS: Maybe this will be closed as not programming related. But I'm a programmer and I have this problem. My work is software development but i don't want to lose this client and the only solution I can think of is to find a way for the client to understand the scope so we can hire a qualified DBA to provide them with the service they require.
Edit: We are in a Latin American country with clients in the Spanish speaking region. My guess is that in more developed countries there is a culture that knows how delicate the situation is.
This is definitely one of those 'you can lead a horse to water, but you can't make them drink' situations.
My recommendation here would be to quote the DBA services as hourly, and make the rate high enough that you can outsource the work if you decide you want to. When (not if) the SQL servers start to have problems, the firm is on the hook.
I would also recommend that you include in your quote a non-optional 2 hour database technology review once per year. This is your opportunity to say 'You spent XXX on database maintenance this year, most of which was spent fighting fires that could have been easily avoided if you had just spent XXXX/4 and hired a DBA. We care about you as a customer, and we want you to save money, so we really recommend that you commit to using a DBA to perform periodic preventative maintenance'.
I would also recommend that you categorize any support requests as having root cause b/c of database maintenance vs other causes. This will let you put a nice pie chart in front of the customer during their annual review (which they are going to pay you to perform). It is critical to manage the perception so they don't think your code is causing the problems. You might even go so far as to share these metrics (db related issue vs non-db related issue) with them on a quarterly basis.
Sometimes people need to experience pain before they change. The key is to not be in between the hammer and their thumb as they learn the lesson, and hourly quoted work is one way of doing this.
As a side note, this sort of question is of great interest to a large number of developers. I'd say that this sort of thing could impact a programmer's quality of life more than any algorithm or library question ever could. Thanks for asking it!
No DBA on a system that size is a disaster waiting to happen. If they don't understand that, they are not qualified to run a database that size. I'd recommend that they talk to other companies with similar sized databases and have them ask them about their DBAs and what they do for them, and if they think they could survive without them.
Perhaps the link below from MS SQL Tips could give you some good talking points. But people who aren't technical wont respond to a technical explanation of the necessity of good DBA you are likley going to have to work toward proving the cost of bad DBA. Work out the worst case scenarios and see how they feel about them. If you can make it seem like a good financial move (and I think we all know it is) it will be an easy sell.
http://www.mssqltips.com/tip.asp?tip=1278
My previous job involved maintenance and programming for a very large database with massive amounts of data. Users viewed this data primarily through an intranet web interface. Instead of having a table of user accounts, each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc., as well as permitting us to control access through the RDBMS itself instead of using our own application logic.
Is this a good setup, assuming you're not on the public intranet and dealing with potentially millions of (potentially malicious) users or something? Or is it always better to define your own means of handling user accounts, your own permissions, your own application security logic, and only hand out RDBMS accounts to power users with special needs?
I don't agree that using the database for user access control is as dangerous others are making it out to be. I come from the Oracle Forms Development realm, where this type of user access control is the norm. Just like any design decision, it has it's advantages and disadvantages.
One of the advantages is that I could control select/insert/update/delete privileges for EACH table from a single setting in the database. On one system we had 4 different applications (managed by different teams and in different languages) hitting the same database tables. We were able to declare that only users with the Manager role were able to insert/update/delete data in a specific table. If we didn't manage it through the database, then each application team would have to correctly implement (duplicate) that logic throughout their application. If one application got it wrong, then the other apps would suffer. Plus you would have duplicate code to manage if you ever wanted to change the permissions on a single resource.
Another advantage is that we did not need to worry about storing user passwords in a database table (and all the restrictions that come with it).
I don't agree that "Database user accounts are inherently more dangerous than anything in an account defined by your application". The privileges required to change database-specific privileges are normally MUCH tougher than the privileges required to update/delete a single row in a "PERSONS" table.
And "scaling" was not a problem because we assigned privileges to Oracle roles and then assigned roles to users. With a single Oracle statement we could change the privilege for millions of users (not that we had that many users).
Application authorization is not a trivial problem. Many custom solutions have holes that hackers can easily exploit. The big names like Oracle have put a lot of thought and code into providing a robust application authorization system. I agree that using Oracle security doesn't work for every application. But I wouldn't be so quick to dismiss it in favor of a custom solution.
Edit: I should clarify that despite anything in the OP, what you're doing is logically defining an application even if no code exists. Otherwise it's just a public database with all the dangers that entails by itself.
Maybe I'll get flamed to death for this post, but I think this is an extraordinarily dangerous anti-pattern in security and design terms.
A user object should be defined by the system it's running in. If you're actually defining these in another application (the database) you have a loss of control.
It makes no sense from a design point of view because if you wanted to extend those accounts with any kind of data at all (email address, employee number, MyTheme...) you're not going to be able to extend the DB user and you're going to need to build that users table anyway.
Database user accounts are inherently more dangerous than anything in an account defined by your application because they could be promoted, deleted, accessed or otherwise manipulated by not only the database and any passing DBA, but anything else connected to the database. You've exposed a critical system element as public.
Scaling is out of the question. Imagine an abstraction where you're going to have tens or hundreds of thousands of users. That's just not going to manageable as DB accounts, but as records in a table it's just data. The age old argument of "well there's onyl ever going to be X users" doesn't hold any water with me because I've seen very limited internal apps become publicly exposed when the business feels it's could add value to the customer or the company just got bought by a giant partner who now needs access. You must plan for reasonable extensibility.
You're not going to be able to share conn pooling, you're not going to be any more secure than if you just created a handful of e.g. role accounts, and you're not necessarily going to be able to affect mass changes when you need to, or backup effectively.
All in there seems to be numerous serious problems to me, and I imagine other more experienced SOers could list more.
I think generally. In your traditional database application they shouldnt be. For all the reason already given. In a traditional database application there is a business layer that handles all the security and this is because there is such a strong line between people who interact with the application, and people who interact with the database.
In this situation is is generally better to manage these users and roles yourself. You can decide what information you need to store about them, and what you log and audit. And most importantly you define access based on pure business rules rather than database rules. Its got nothing to do with which tables they access and everything to do with whether they can insert business action here. However these are not technical issues. These are design issues. If that is what you are required to control then it makes sense to manage your users yourself.
You have described a system where you allow users to query the database directly. In this case why not use DB accounts. They will do the job far better than you will if you attempt to analyse the querys that users write and vet them against some rules that you have designed. That to me sounds like a nightmare system to write and maintain.
Don't lock things down because you can. Explain to those in charge what the security implications are but dont attempt to prevent people from doing things because you can. Especially not when they are used to accessing the data directly.
Our job as developers is to enable people to do what they need to do. And in the situation you have described. Specifically connect to the database and query it with their own tools. Then I think that anything other than database accounts is either going to be insecure, or unneccasarily restrictive.
"each user account was a real first-class account in the RDBMS, which permitted them to connect with their own query tools, etc.,"
not a good idea if the RDBMS contains:
any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
credit card information or other customer credit info (POs, lines of credit etc)
personal information (ssn, dob, etc)
competitive, proprietary, or IP information
because when users can use their own non-managed query tools the company has no way of knowing or auditing what information was queried or where the query results were delivered.
oh and what #annakata said.
I would avoid giving any user database access. Later, when this starts causing problems, taking away their access becomes very dificult.
At the very least, give them access to a read-only replica of the database so they can't kill your whole company with a bad query.
A lot of database query tools are very advanced these days, and it can feel a real shame to reimplement the world just to add restrictions. And as long as the database user permissions are properly locked down it might be okay. However in many cases you can't do this, you should be exposing a high-level API to the database to insert objects over many tables properly, without the user needing specific training that they should "just add an address into that table there, why isn't it working?".
If they only want to use the data to generate reports in Excel, etc, then maybe you could use a reporting front end like BIRT instead.
So basically: if the users are knowledgeable about databases, and resources to implement a proper front-end are low, keep on doing this. However is the resource does come up, it is probably time to get people's requirements in for creating a simpler, task-oriented front-end for them.
This is, in a way, similar to: is sql server/AD good for anything
I don't think it's a bad idea to throw your security model, at least a basic one, in the database itself. You can add restrictions in the application layer for cosmetics, but whichever account the user is accessing the database with, be it based on the application or the user, it's best if that account is restricted to only the operations the user is allowed.
I don't speak for all apps, but there are a large number I have seen where capturing the password is as simple as opening the code in notepad, using an included dll to decrypt the configuration file, or finding a backup file (e.g. web.config.bak in asp.net) that can be accessed from the browser.
*not a good idea if the RDBMS contains:
* any information covered by HIPAA or Sarbanes-Oxley or The Official Secrets Act (UK)
* credit card information or other customer credit info (POs, lines of credit etc)
* personal information (ssn, dob, etc)
* competitive, proprietary, or IP information*
Not true, one can perfectly manage which data a database user can see and which data it can modify. A database (at least Oracle) can also audit all activities, including selects. To have thousands of database users is also perfectly normal.
It is more difficult to build good secure applications because you have to program this security, a database offers this security and you can configure it in a declarative way, no code required.
I know, I am replying to a very old post, but recently came across same situation in my current project. I was also thinking on similar lines, whether "Application users be Database users?".
This is what I analysed:
Definitely it doesn't make sense to create that big number of application users on database(if your application is going to be used by many users).
Let's say you created X(huge number) of users on database. You are opening a clear gateway to your database.
Let's take a scenario for the solution:
There are two types of application users (Managers and Assistant). Both needs access to database for some transactions.
It's obvious you would create two roles, one for each type(Manager and Assistant) in database. But how about database user to connect from application. If you create one account per user then you would end up linearly creating the accounts on the database.
What I suggest:
Create one database account per Role. (Let's say Manager_Role_Account)
Let your application have business logic to map an application user with corresponding role.(User Tom with Manager role to Manager_Role_Account)
Use the database user(Manager_Role_Account) corresponding to identified role in #2 to connect to database and execute your query.
Hope this makes sense!
Updated: As I said, I came across similar situation in my project (with respect to Postgresql database at back end and a Java Web app at front end), I found something very useful called as Proxy Authentication.
This means that you can login to the database as one user but limit or extend your privileges based on the Proxy user.
I found very good links explaining the same.
For Postgresql below Choice of authentication approach for
financial app on PostgreSQL
For Oracle Proxy Authentication
Hope this helps!
It depends (like most things).
Having multiple database users negates connection pooling, since most libraries handle pooling based on connection strings and user accounts.
On the other hand, it's probably a more secure solution than anything you or I will do from scratch. It leaves security up to the OS and Database server, which I trust much more than myself. However, this is only the case if you go to the effort to configure the database permissions well. If you're using a bunch of OS/db users with the same permissions,it won't help much. You'll still get an audit trail, but that's about it.
All that said, I don't know that I'd feel comfortable letting normal users connect directly to the database with their own tools.
I think it's worth highlighting what other answers have touched upon:
A database can only define restrictions based on the data. Ie restrict select/insert/update/delete on particular tables or columns. I'm sure some databases can do somewhat cleverer things, but they'll never be able to implement business-rule based restrictions like an application can. What if a certain user is allowed to update a column only to certain values (say <1000) or only increase prices, or change either of two columns but not both?
I'd say unless you are absolutely sure you'll never need anything but table/column granularity, this is reason enough by itself.
This is not a good idea for any application where you store data for multiple users in the same table and you don't want one user to be able to read or modify another user's data. How would you restrict access in this case?