Queues in salesforce can be used to make a bunch of users as owners to a record there by providing record level security to the users in that Queue and on the other hand in team selling also we can make users to view the record (although they are not made as owners) so, my question is what ever we are trying to achieve in team selling can also be achieved by Queues then why do we have these 2 concepts in salesforce
Because they're for completely different things. (That's an admin/architecture question rather than coding, post these on dedicated https://salesforce.stackexchange.com/ for better visibility)
Queues are for "unassigned work". Customer Support Tickets, optionally split to tier 1 and tier 2 (escalations). Leads you purchased from somewhere and now you need to to go through them, nurture them, hopefully convert. Typically you grab a case/lead/whatever from the queue, you claim ownership - it leaves the queue. It may or may not be still visible to your teammates depending on sharing rules... but typically it's "done", taken care of. If the support ticket is too tricky or you go on holidays maybe you'll need to put it back to the queue, it happens. But out of the box - it left the queue = other guys lose visibility of it.
Team selling is different. It's my opportunity, I want to reap the commission from it, I want to keep being the owner. But I recognise I need help to win it. Maybe from marketing guy or another sales rep, maybe I'll agree to 20% cut. Maybe I need in-house developer's help to prototype something that will win this client over.
Maybe we have strict data visibility rules - each country sees only this country's data - but this opportunity happens to be in some border town and I'd like to invite guy from another country's team to help because their warehouse is closer, it'd make more sense to fulfill the order from their side.
You'd make such decisions on case-by-case basis, depending on opportunity. And probably the team would be slightly different each time (or maybe it wouldn't. If you have a dedicated support rep that's doing all this client's cases - he/she could auto cascade to Opportunities and Cases, offer you some unique insight how to wiin the deal).
So it's not exactly same thing as queues where people just pick up next task out of a pile.
Related
Assuming a e commerce web app has a high amount of requests, how do I prevent two users from choosing the only product left? Should I check the quantity when adding to shopping list or payment? Is it using a field to record quantity of selected product in DB is bad way? How does the large e commerce web app like amazon deal with conflict problem?
Several options that I know :
For the RDBMS that support ACID , you can use optimistic locking technique on the product table. Unless it is very often that many users hit the buying button on the same product at the nearly same times ,it should work pretty well.(For how many users does the 'many' means, you have to measure it. I think 1k should be no problem. Just my guess , don't take it for granted)
Do not check it and let users to buy it. Adjust the business flow to handle it. For example, when an user hits the buying button ,tell him his order is just accepted and will be processed but not guarantee he must able to buy it. Then in the later stage when you find that there is not enough inventory to ship the product to him , send an email to apologise and refund to him.
Also in the real business , it is common that the product inventory can go to negative and still accepting orders but tell the user he will get the product at XXX days later. The business can then produce or order more product from the supplier after receiving the money.
If you are buying iPhone on the Apple web site , it also works like this.
It really depends upon the number of concurrent users here. In the case of millions, the NoSQL approach is prefered to manage the basket with eventual consistency then the buying process would go with ACID to ensure the product can be sold.
For less users, you can rely on an ACID database.
If you are not sure, you may go with a database that has ACID capabilities but can as well allow you to work in an eventual consistency way or that can implement the concept of sharding for scalability purpose. To my knowledge Oracle can do these 3 things: COMMIT NO WAIT, COMMIT and Sharding deployment.
HTH
We use a tool that tracks individual users' mouse movements and clicks on our site. Right now it only tracks anonymous visitors, but we're thinking of using it to track specific logged in users' data. We'd be using it for analytics, but we'd like to have the data in case we need to analyze how a particular person uses the site.
Are people, in general, alright with this? Does this constitute privacy infringement?
The short answer is it is your site, for the most part (for now) you can track whatever you want on it.
However, some things to consider...
a) 3rd party analytics tools have their own privacy policies and Terms of Services that may or may not allow this, so if you are using something like Google Analytics, Omniture SiteCatalyst, WebTrends, Yahoo Web Analytics, etc.. then you need to read over their Privacy Policy and Terms of Service to make sure you are allowed to track this sort of thing. Offhand I don't think any of the ones I mentioned disallow tracking mouse movements/clicks specifically (and in fact, some of them have features/plugins for it, called "clickmap" tracking, or similar), but some do have restrictions on other data you may couple with this. For example, I know Google does not allow you to associate any data with the user's IP address. You cannot send it to GA in a custom variable, nor can you store it on your own server in any way that you can associate it with data you send to GA (for example, storing the user's IP in your own database along with a unique id, and then sending the unique id to GA, where you can then lookup IP by that unique id).
b) Privacy is indeed a concern that is currently being discussed by the powers-that-be, and your ability to track certain things may indeed be limited in the future. For now, it's mostly about personally identifiable information, and it's mostly happening in Europe, and tracking mouse movement/clicks generally isn't personally identifiable, but who knows what the future may bring.
c) Make sure you understand the costs involved in tracking mouse movements/clicks. In order to track something, a request has to be made, data sent somewhere. The more granular the data, the more requests and/or data needs to be sent. Whether it is your own baked up tracking solution on your own server or a 3rd party, this will cost something one way or the other. Imagine sending a request to a server for every x,y position of the mouse as it moves...this could quickly add up, and a lot of 3rd party solutions place a limit on how many requests can be made per visit(or) or day on an account.
d) On that note, if you are using a 3rd party solution, tracking something this granular may affect tracking more important stuff. As mentioned in "c", many 3rd party solutions limit how many requests can be made per visit(or) or day on your account, etc.. and if you hit the limit, any requests after that won't be tracked. Imagine if you have tracking on a sale confirmation page, tracking details about a sale made, which is very important tracking, being tossed out because of too many requests of mouse movements on some random page...
e) On that note... consider how actionable tracking mouse movements and clicks really is to you. This is a question you have to really ask yourself whenever you want to track something: "How actionable is this?" Basically, imagine yourself having the tracking in place and looking at the data...then what? What will you do with that data? Assuming the ultimate goal is to make more money, increase conversions on your site, etc.. do you really think knowing the paths a mouse cursor took on a given webpage will help you increase sales/conversions? How will you be able to know if the mouse movements are related to content on your page, or if they were just some random jerks/movements while reading content or making room on a desk, etc..? At best, the data will be polluted...
Clicks on links or specific action buttons on a page? Sure, those are certainly worth tracking. And most 3rd party solutions automatically track a lot of that stuff, or offer custom coding solutions for manual wiring up of things. And there are plenty of reports that can be made showing activity from them.
Imagine that you want to design a tennis booking system.
You have 5 tennis clubs as partners with no online api allowing you to check on their side if a court is booked or not: You have to build this part as well.
Every time a booking is done on their side you want it to be known by our system. Probably using a POST request form tennis partner to our server.
Every time a booking is done on our website, we want to push the booking to their system. The difficulty is that their system need to be online and accessible from outside. Ip may change, we have to use a dns updater.
In case their system is not available we still accept the booking and fallback to an async email with 'i confirm booking/reject booking' link sent to the club.
I find the whole process quite complex and was wondering about the way online hotel booking system and hotel were working. Do they all have their data open and online ?
The good thing is that the data will grow large and fits nicely to some no SQL ;) like couch db
There are several questions here, let me try and address each one...
Since this appears to be an internet application with federated servers, using the implied HTTP Protocol makes a lot of sense. This could be done via Form POSTs, GET, or even REST-ful submission of some custom data structure. In the end, the exact approach to use will need to come down to the size and complexity of the information being communicated. Many architectures employ these approaches and often combine them with encrypted, signed, and/or encoded payloads for security. One short-fall to consider with these approaches is that they will require you to clearly communicate all request / response message formats, field ranges, and variations since these mechanisms are not really self-describing. On the other hand, these patterns use very common protocols, are easily understood, easy to implemented, and are typically lean on-the-wire.
In constrast, architectures with very complex structures often chose to use WSDL-based web services. Also driven by common standards, these tend to be self-describing, inherently versionable, although they can take more time and energy to implement. There are a lot of advantanges to web services which are driven by many WS-* standards which may be worth investigating further in your case.
As for the reservation process... many similar architectures will employ an orchestration model such as the following:
Find open booking spaces
Make a reservation for a booking space. This places an expiring lock on a space while the requestor fills in all required booking information. This mitigates against race conditions that could lead to multiple bookings for the same space
Once all required booking information is received and validated the booking is confirmed and permamently locked from use by other requestors
As for the SQL-style DB comment, I can't really say given the amount of information supplied. With that said, my instincts tell me a SQL-style DB is completely reasonable for this problem set. I have databases with many pedabytes and have very high SLA's. You implied a need for high availability and SQL-based databases have a few decades of proven support behind them in this area.
Hope this helps.
I think you will find most on-line hotel reservation systems aren't really on-line. My experience is that those companies (not the hotels themselves) offering on-line booking systems also insist that the hotel itself also books their rooms on-line using the same system.
Everything works fine as long as connectivity is not an issue - and in small motels scenario it normally will. Of course the bigger hotels use the same system the airlines do and they have dedicated communications links for the purpose. The reservations are of course maintained on one central computer with appropriate backup links etc etc etc.
It is very easy for individual tennis clubs to offer their own real-time online booking systems using their own database/website with programs like MyCourts offers however once you want to link more than one clubs facilities then you really don't have much option other than to have a centralized server that both the user and the club both have to use to reserve facilities.
I'm coding a new {monthly|yearly} paid site with the now typical "referral" system: when a new user signs up, they can specify the {username|referral code} of other user (this can be detected automatically if they came through a special URL), which will cause the referrer to earn a percentage of anything the new user pays.
Before reinventing the wheel, I'd like to know if any of you have experience with storing this kind of data in a relational DB. Currently I'm using MySQL, but I believe any good solution should be easily adapted to any RDBMS, right?
I'm looking to support the following features:
Online billing system - once each invoice is paid, earnings for referrals are calculated and they will be able to cash-out. This includes, of course, having the possibility of browsing invoices / payments online.
Paid options vary - they are different in nature and in costs (which will vary sometime), so commissions should be calculated based on each final invoice.
Keeping track of referrals (relationship between users, date in which it was referred, and any other useful information - any ideas?)
A simple way to access historical referring data (how much have been paid) or accrued commissions.
In the future, I might offer to exchange accrued cash for subscription renewal (covering the whole of the new subscription or just a part of it, having to pay the difference if needed)
Multiple levels - I'm thinking of paying something around 10% of direct referred earnings + 2% the next level, but this may change in the future (add more levels, change percentages), so I should be able to store historical data.
Note that I'm not planning to use this in any other project, so I'm not worried about it being "plug and play".
Have you done any work with similar requirements? If so, how did you handle all this stuff? Would you recommend any particular DB schema? Why?
Is there anything I'm missing that would help making this a more flexible implementation?
Rather marvellously, there's a library of database schemas. Although I can't see something specific to referrals, there may be something related. At least (hopefully) you should be able to get some ideas.
So, I work in a fairly small IT section. We have a trouble ticketing system that about half of our end users use. Some of my coworkers don't really do much to encourage our end users to use the system we have in place. The end result? Constant interruptions because end users will get us by IM or come to our offices directly for trivial things. This can obviously make it difficult to do a good job of writing code.
Now, I suppose I could just say "hey, would you mind filling out a trouble ticket next time?", but then I'd come off as the bad guy because others won't do that. I also don't want end users to feel that I'm unapproachable. I just want them to understand that there's a proper way to ask for help.
So what's the best thing for me to do in a situation like this?
Make it appealing to do so.
Mention to the user that issues with trouble tickets are viewed by the entire development team and have been found to get fixed significantly faster. Say that anything without a ticket has the potential to get lost in the shuffle. Provide them outward facing links so they can view the progress and developer/support comments on their ticket. Provide email alerts so they feel like they are part of the process and have instant information about their issue.
Make it as frictionless as possible.
Make the user entry part of the system as easy to use and as intuitive as possible. No one likes filling out tickets and I'm certainly not going to jump through any hoops to do so. No logins, no sign-ins, just type out my issue and contact information and go.
Talk with your team.
Ultimately, no amount of hard work on the above systems is going to matter unless your team and you are on the same page. Call for a team meeting and talk with them about the issue. With your boss present, try and put it in terms he can understand. Mention valuable time lost, issues tracking customer problems which aren't in the system, etc, etc.
Sounds like your manager is letting you down by not forcing users to submit a ticket before getting help. The problem starts there and only continues to your co-workers allowing such behavior. We use redmine at work for application support and have made good progress in telling users "submit a ticket and we will look in to it" but it has to be a consistent voice from all people involved.
Use a little psychology on them. For people that don't send in trouble tickets, remind them that 80% of the people in their department use the ticketing system. Even if it is a lie, it will encourage good behavior because of the bandwagon effect. Remember that the more similar the person is to demographic statistic, the more likely it is to influence their behavior. So "your immediate coworkers" will work better than "people in this entire company."
The people that use the ticketing system should get a gold star, no, seriously.
There was a very brief article in February's Harvard Business Review on using social pressure to influence behavior. It discussed some new research but the article didn't include references.
You don't. Users hate that stuff even I do. Instead your policy should be "don't make me think". You have to collect all you need yourself and automatically handle this in an invisible way to your users. After they opt in at install.
You probably won't make much headway unless you convince your coworkers to use the system first. After you've all agreed on the process you want, then you can talk to your users. If everyone on your team is playing by the same rules, you can probably force your users to use the system by having slow turn-around times for issues not entered into the system, or maybe even forget them altogether.
However, even IF you can convince both your coworkers and your users to enter tickets, you'll probably still find the tickets are incomplete/not informative. We've all seen plenty of tickets like "Feature X is broken, fix it plz" and offer no other information. Depending on the number of tickets you get per day, I would probably just bite the bullet and walk over the user and see what their problem is first hand.
We often log a ticket on the user's behalf in this sort of case.
At my old workplace, I was told that nothing could be done without a trouble ticket. When I asked why, I was told that the support team's productivity was measured by using trouble tickets. This had the effect of forcing me to use trouble tickets (since they were required), and giving me the motivation to do so (I didn't want my coworkers to look bad).
At my new workplace, all technical support is subcontracted out. I literally have to call tech support, and they create a ticket on my behalf.
Also - stop encouraging the behavior. Use your IM filtering options to only appear online to the dev team. Don't check your email - or setup filters that filter the high priority stuff (your boss, your dev team) to your inbox, and everything else to a folder you check once a day or once every other day.
Simucal's advice is good. You -will- have to tell them to "file a ticket" instead, at some point. If you ask them after the fact, they aren't going to care because they got what they needed.
A great way to handle this is to have a dedicated person for support. My team did this, and it helped our productivity immensely and eliminated at least 90% of our interruptions.
Barring that (or lieu of), you can each rotate daily as to who gets to handle user requests. This has the upshot of making a trouble ticket more-or-less required; its needed to keep track of what happened in the request when someone else starts working on it. Over time, this also brings more cohesion to your processes: people create small scripts to do common tasks, work that is done is moved into revision control, etc.