I'm having a bit of a trouble here... I'm trying to enable a few new email-to-case (e2c) rules in an existing org which already has the on-premise e2c java toolkit operating.
In a sandbox, I've enabled On-Demand e2c and configured a gmail account to redirect to the SFDC provided alias. It takes in the case just fine, but for some reason the record type is being changed after it has been created.
I've specified a record type in the e2c configurtion but after it is created, it changes to the default value for the either the System Admin profile or the Automated Case User (I can't tell which it is, as that user has Sys Admin profile). I've already confirmed that it is happening post create (see underline section below) and is not attributed to a workflow or trigger.
When I change the default record type of the Sys Admin profile to CertSec Case Working, it does not change the record type (which is what I want)... but that is not an option as there are other E2C rules using that. Furthermore, the Sys Admin profile already has access to the CertSec Case Working record type, so it seems like a bug. Help!
REDACTED
Changed Priority Change Time to 9/24/2012 3:06 PM.
Changed Case Record Type from CertSec Case Working to Case Working.
I receieved a question via email which I'll repost here, and answer:
Hi Greg,
I'm trying to interpret the Force.com Streaming API limits noted in the documentation. These are my questions:
1. "Maximum Number of Topics: 20" - is that referring to the total number of PushTopic records? Is that limit per user or per org?
2. "Maximum number of clients (subscribers) per topic: 10" - does that mean if I build a VF page that allows users to select streams to "follow" and deploy that into an org with 100 users, only 10 of them can subscribe to the same topic? Is that limit of 10 at any given moment, or is there a duration for which a subscription lives and "blocks" other subscribers?
I have an old application that uses Web-To-Lead. I'm updating it to use the REST API. We have a bunch of assignment rules set up for Leads. When we create a lead through Web-To-Lead, the Lead is assigned according to our assignment rules. However, when we create a Lead through the REST API, the assignment rules are completely ignored, and the Lead is assigned to the account whose credentials we used to authenticate through OAuth. This has slowed our sales team to a crawl, because now they have to assign leads by hand.
