I need to create a case Object with case Number assigned to it in my test class
public static Case CreateCase(Id conId,Id accId){
Case caseObj = new Case(
ContactId = conID,
AccountId = accId,
Status = 'Working',
Origin = 'Phone',
CaseNumber = '11111111');
return caseObj;
}
But it throws error saying, caseNumber field is not writable.
I need to create a case object with CaseNumber field..is there any other way?
To borrow a consulting cop-out, I think the answer depends on your business processes and objectives. Girbot made a great recommendation to engage the business in conversation on this topic. Or, put in other words, please consider your organization's unique context.
With that said, let's explore (thinking out loud) a few business considerations, and then examine some options. Hopefully we'll arrive at some guidelines for using the Parent Case field, that you can apply to your unique organization.
Typically front-line staff care about two things:
Both of the above concerns usually drive a need to have a system that allows for efficient routing and handling of cases, so we assume that users want to close cases as quickly as reasonable.
Support managers usually care about a couple of things:
Managers usually look at data in aggregate, which in Salesforce means using Salesforce1 Reporting (formerly known as Salesforce Analytics).
The hypothetical call about a broken printer and a new monitor you described can be logged in one of the following ways:
You've already noted that two departments are involved, one for the broken printer and one for the new monitor. If you're not using Case Teams, you probably will need or want to create a separate case and assign that to the other department.
Plus, if your organization reports on the number of cases handled by reps, chances are those reports are based on Case Owner, in which case the rep in the supporting department won't get credit for working on the case.
Having two cases solves the work routing and crediting problem, to distribute work to two departments. However, at a glance you won't be able to tell that a related case was created. Furthermore, you're building a habit that is not conducive to introduce any kind of automation for related cases (e.g., time tracker roll-ups).
Basically this is the previous option but with a link between the cases. The relationship allows for quick visibility to see that a related case exists, and the relationship would facilitate any kind of "related case" automation you may want to add.
To keep things clean, and to simplify life for the customer by just providing the customer one reference number (i.e., Case Number), I suggest:
If only two people are involved, this would really seem like overkill. However, for more complicated problems or situations where the primary support rep is not the one working to solve the problem, you may want to go this route.
One example that comes to mind is a technical support call that reveals two deeper, distinct problems, requiring involvement from separate R&D departments. I may call Premier Support about a Visualforce page, and that ends up being escalated separately to the Visualforce team and the Apex team.
Sorry for the long-winded response, but here are my direct answers to your questions. It bears noting that in the scenario you described, I think the third option (2 cases in parent-child relationship) is probably optimal.
Do I duplicate the Activity, marking one as "real" for statistical purposes?
No. I don't recommend duplicating activities (i.e., Task records). Log customer interactions only on the parent case.
Do I make a shell parent Case, two child Cases, and keep the initial call on the parent (and then provide a UI on the child cases to see the activities on the parent)?
No. This is the fourth option I described, and I do think it's overkill for the scenario you described. Using two cases will probably meet your business requirements.
Do I do something else entirely?
Yes. Create two cases in parent-child relationship. This makes it respect the reality that you described, "as far as the caller is concerned, [we'd] like to treat this as one call." One case number given to the customer, two case numbers known to the organization.
If you want to mock an SObject with an auto-number field pre-filled in, do the following
Foo__c foo = (Foo__c) Json.deserialize('{"name" : "abc"}',Foo__c.class);
This is an object in memory, not in the database. You can add additional fields to mock in the JSON string expression.
Note that the JSON value for "name" doesn't even have to adhere to the auto-number format for the object.
UPDATE - when you need to insert the mocked SObject
@isTest
private class MyTestClass {
private static testMethod void test() {
CustomObj__c obj = new CustomObj__c();
obj.Field1__c = 'value';
//so on
insert obj;
obj = [select id, field1__c, name from CustomObj__c where id = :obj.id LIMIT 1]; // add this line
Boolean flag = SomeClassThatUsesCustomObj.StaticMethod(obj);
System.assertsEqual(true, flag);
}
}
Auto-number field values of mocked SObjects must be queried before they can be referenced later in the code path. Note that @FernandoGavinho had this answer first
Best Answer
It has typo error from "form" to "from" in a select statement: