I'm a new SF customer. My company has been an SF user for a long time, but we just began using SupportForce, with the introduction of email-to-case and limited professional access to the API. We spent several months speccing out exactly how we want SF to work for support and then worked with Rohit from SF professional services for a week of customization. This got us pretty far, and Rohit was extremely competent and helpful, but we still have some open issues that I am trying to resolve internally. I'd like to get the communities sense on whether the issues can be resolved and whether I'm headed in the right direction with thoughts on resolutions. Again, it's important to note that we are only a Professional customer. (We would upgrade support to Enterprise, but our sales organization has no need for it so the pricing is way out of reach.)
Questions:
I know that some API access is enabled in professional. I installed the excel integration and it worked well for me. And we wrote the following SControl, which runs successfully. What are the limits? Is there any professional-specific documentation on the API and SControls?
<SCRIPT LANGUAGE="JavaScript"> var redirectString = "/cases/caseowneredit.jsp?retURL=%2F{!Case_ID}&save=1&ids={!Case_ID}&caseowner='{!User_FullName}'"; function redirect() { <!-- document.write(redirectString);--> parent.frames.location.replace(redirectString); } redirect(); </SCRIPT>
General documentation. I have found it *very* difficult to do things that seem simple because of a lack of documentation. Is there more documentation out there that I just don't know about? All I have been using is the documentaiton that is linked to off of the "?help" link on the admin setup screens.
Problem: A case creation mechanism that enforces contract verification, but still allows a "special" case to be created of type field_trial. Solution: Our current solution is to have a custom object (called 'DeviceInfo') with account as the master object for storing contracts. The custom object would include standard contract fields including expiration date, along with our hardware serial numbers and config info for each device. Then we will create a new page as the initial step in case creation. This page would be an SControl which would allow account lookups and show matching accounts in a table with info indicating whether the account has an associated contract which is valid.
Problem: A mechanism for maintaining device configuration on the account. Also a mechanism for selecting an appropriate config or creating a new config during case creation/edit. Solution: Utilize the solution from the previous problem. The new page for account contract verification would enable copying the config info from the DeviceInfo into the new case object. If necessary, the config select could happen in a separate SControl, triggered by a link on the case and thus happening after case creation.
Problem: Currently we use reports instead of queues. Looking at a report for all the cases I own, it does not appear that there is a way to determine if email-to-case has updated the case. There is no flag on the case to indicate that it has received an update. There is a task which is created by email-to-case. But I cannot figure a way to show as a column in the report whether there exist any open activities on the case. This seems like it should be simple, but right now i have no solution.
Problem: No way to view the history of *all* interactions on a case in chronological order. The Email object shows only emails. There is no good way to make phone conversations appear. The comments object doesn't contain emails. The activity history doesn't contain emails which are sent from the system through the email object. Solution: We have two solutions. The first is to remove the Email object from the case and only use Activity History. This is problematic for several reasons: first, the Activity History task does not contain the body of the email, you have to click a small link on the Task page; second, we don't really want to use tasks at all and we don't want to have to close the email task, it is wasted clicks in our workflow; third, the link on the Activity History object to send an email does not quote the email that we are replying to and it does not append the cc list. The second solution is even more of a hack. We could simply record phone conversations by sending an email from the Email object. This is dumb because the to field of the email prepopulates with the customer and we will end up accidentally sending some of these to the customer which could be bad.
Again, at this point I am only interested in general thoughts. I will probably have specific questions about several of these things as I get further into implementation. It's just that I don't want to use up all my good answer karma on my first email.
I'm a new SF customer. My company has been an SF user for a long time, but we just began using SupportForce, with the introduction of email-to-case and limited professional access to the API. We spent several months speccing out exactly how we want SF to work for support and then worked with Rohit from SF professional services for a week of customization. This got us pretty far, and Rohit was extremely competent and helpful, but we still have some open issues that I am trying to resolve internally. I'd like to get the communities sense on whether the issues can be resolved and whether I'm headed in the right direction with thoughts on resolutions. Again, it's important to note that we are only a Professional customer. (We would upgrade support to Enterprise, but our sales organization has no need for it so the pricing is way out of reach.)
Questions:
I know that some API access is enabled in professional. I installed the excel integration and it worked well for me. And we wrote the following SControl, which runs successfully. What are the limits? Is there any professional-specific documentation on the API and SControls?
<SCRIPT LANGUAGE="JavaScript"> var redirectString = "/cases/caseowneredit.jsp?retURL=%2F{!Case_ID}&save=1&ids={!Case_ID}&caseowner='{!User_FullName}'"; function redirect() { <!-- document.write(redirectString);--> parent.frames.location.replace(redirectString); } redirect(); </SCRIPT>
General documentation. I have found it *very* difficult to do things that seem simple because of a lack of documentation. Is there more documentation out there that I just don't know about? All I have been using is the documentaiton that is linked to off of the "?help" link on the admin setup screens.
Problem: A case creation mechanism that enforces contract verification, but still allows a "special" case to be created of type field_trial. Solution: Our current solution is to have a custom object (called 'DeviceInfo') with account as the master object for storing contracts. The custom object would include standard contract fields including expiration date, along with our hardware serial numbers and config info for each device. Then we will create a new page as the initial step in case creation. This page would be an SControl which would allow account lookups and show matching accounts in a table with info indicating whether the account has an associated contract which is valid.
Problem: A mechanism for maintaining device configuration on the account. Also a mechanism for selecting an appropriate config or creating a new config during case creation/edit. Solution: Utilize the solution from the previous problem. The new page for account contract verification would enable copying the config info from the DeviceInfo into the new case object. If necessary, the config select could happen in a separate SControl, triggered by a link on the case and thus happening after case creation.
Problem: Currently we use reports instead of queues. Looking at a report for all the cases I own, it does not appear that there is a way to determine if email-to-case has updated the case. There is no flag on the case to indicate that it has received an update. There is a task which is created by email-to-case. But I cannot figure a way to show as a column in the report whether there exist any open activities on the case. This seems like it should be simple, but right now i have no solution.
Problem: No way to view the history of *all* interactions on a case in chronological order. The Email object shows only emails. There is no good way to make phone conversations appear. The comments object doesn't contain emails. The activity history doesn't contain emails which are sent from the system through the email object. Solution: We have two solutions. The first is to remove the Email object from the case and only use Activity History. This is problematic for several reasons: first, the Activity History task does not contain the body of the email, you have to click a small link on the Task page; second, we don't really want to use tasks at all and we don't want to have to close the email task, it is wasted clicks in our workflow; third, the link on the Activity History object to send an email does not quote the email that we are replying to and it does not append the cc list. The second solution is even more of a hack. We could simply record phone conversations by sending an email from the Email object. This is dumb because the to field of the email prepopulates with the customer and we will end up accidentally sending some of these to the customer which could be bad.
Again, at this point I am only interested in general thoughts. I will probably have specific questions about several of these things as I get further into implementation. It's just that I don't want to use up all my good answer karma on my first email.
I'm a new SF customer. My company has been an SF user for a long time, but we just began using SupportForce, with the introduction of email-to-case and limited professional access to the API. We spent several months speccing out exactly how we want SF to work for support and then worked with Rohit from SF professional services for a week of customization. This got us pretty far, and Rohit was extremely competent and helpful, but we still have some open issues that I am trying to resolve internally. I'd like to get the communities sense on whether the issues can be resolved and whether I'm headed in the right direction with thoughts on resolutions. Again, it's important to note that we are only a Professional customer. (We would upgrade support to Enterprise, but our sales organization has no need for it so the pricing is way out of reach.)
Questions:
I know that some API access is enabled in professional. I installed the excel integration and it worked well for me. And we wrote the following SControl, which runs successfully. What are the limits? Is there any professional-specific documentation on the API and SControls?
<SCRIPT LANGUAGE="JavaScript"> var redirectString = "/cases/caseowneredit.jsp?retURL=%2F{!Case_ID}&save=1&ids={!Case_ID}&caseowner='{!User_FullName}'"; function redirect() { <!-- document.write(redirectString);--> parent.frames.location.replace(redirectString); } redirect(); </SCRIPT>
General documentation. I have found it *very* difficult to do things that seem simple because of a lack of documentation. Is there more documentation out there that I just don't know about? All I have been using is the documentaiton that is linked to off of the "?help" link on the admin setup screens.
Problem: A case creation mechanism that enforces contract verification, but still allows a "special" case to be created of type field_trial. Solution: Our current solution is to have a custom object (called 'DeviceInfo') with account as the master object for storing contracts. The custom object would include standard contract fields including expiration date, along with our hardware serial numbers and config info for each device. Then we will create a new page as the initial step in case creation. This page would be an SControl which would allow account lookups and show matching accounts in a table with info indicating whether the account has an associated contract which is valid.
Problem: A mechanism for maintaining device configuration on the account. Also a mechanism for selecting an appropriate config or creating a new config during case creation/edit. Solution: Utilize the solution from the previous problem. The new page for account contract verification would enable copying the config info from the DeviceInfo into the new case object. If necessary, the config select could happen in a separate SControl, triggered by a link on the case and thus happening after case creation.
Problem: Currently we use reports instead of queues. Looking at a report for all the cases I own, it does not appear that there is a way to determine if email-to-case has updated the case. There is no flag on the case to indicate that it has received an update. There is a task which is created by email-to-case. But I cannot figure a way to show as a column in the report whether there exist any open activities on the case. This seems like it should be simple, but right now i have no solution.
Problem: No way to view the history of *all* interactions on a case in chronological order. The Email object shows only emails. There is no good way to make phone conversations appear. The comments object doesn't contain emails. The activity history doesn't contain emails which are sent from the system through the email object. Solution: We have two solutions. The first is to remove the Email object from the case and only use Activity History. This is problematic for several reasons: first, the Activity History task does not contain the body of the email, you have to click a small link on the Task page; second, we don't really want to use tasks at all and we don't want to have to close the email task, it is wasted clicks in our workflow; third, the link on the Activity History object to send an email does not quote the email that we are replying to and it does not append the cc list. The second solution is even more of a hack. We could simply record phone conversations by sending an email from the Email object. This is dumb because the to field of the email prepopulates with the customer and we will end up accidentally sending some of these to the customer which could be bad.
Again, at this point I am only interested in general thoughts. I will probably have specific questions about several of these things as I get further into implementation. It's just that I don't want to use up all my good answer karma on my first email.
