-
-
Crowe is providing a webinar on Microsoft Dynamics CRM on January 8, 2009 from 1:00 - 2:30 PM ET. If you are interested, you can click here for more details:
https://www.crowehorwath.com/crowe/AboutUs/Events/detail.cfm?id=413
-
-
Microsoft has changed the way administrators may alter an existing user's Domain and/or Username in CRM 4.0. A knowledge base article exists with detailed instructions, which can be found here: http://support.microsoft.com/kb/930853.
Here is a quick synopsis of the procedure:
- Modify the user account in Active Directory. For example, change the user name, and then change the logon name.
- Open Microsoft Dynamics CRM 4.0 as a System Administrator user.
- Click Settings, click Administration, click Users, and then open the user record that you want to change.
- In the Domain Logon Name box, type an Active Directory user account that is not used by a Microsoft Dynamics CRM 4.0 user record.
~~This should just be any AD user on the network that is not using CRM. It is just a placeholder.
Note If all the Active Directory user accounts are used by Microsoft Dynamics CRM 4.0 user records, create a temporary Active Directory user account.
- Click Save.
- In the Domain Logon Name box, type the Active Directory user account. Then, click Save and Close.
~~This should be the new Username that you wish to use.
Note The Active Directory user account that you type in this step is the account that is used by a Microsoft Dynamics CRM 4.0 user record. The Microsoft Dynamics CRM 4.0 user record is the record for which you want to change the user name and the logon name in Microsoft Dynamics CRM 4.0.
-
-
Each Campaign created using the CRM Marketing Module can have Planning Tasks associated with it. Sorting for the default view of these Planning Task is on the column Name. For many, it may make more sense to sort this view by Due Date, with those Due in the nearest future (or past) at the top of the list (ascending).
Simple, right? We'll just follow the examples in the Microsoft Team Blog post, and.... Wait a minute! There's no "Planning Tasks" view - anywhere. Now what?
Well after looking through various possibilities, The Planning Tasks view under Campaigns actually uses the "All Tasks" view. Modifications to the All Tasks View will be reflected in your list of Campaign Planning Tasks.
-
-
When you need to modify a view in CRM, nine times out of ten you will modify the view in the Settings | Customization | Customize Entities area of CRM. Occassionally however, you will find the need to modify additional views that are not available through this area. Jim Schumacher on the Microsoft Team blog has a great post describing how to access and modify these additional views. The example is for marketing list members - check it out!
-
-
Scenario: I have a CRM 4.0 environment and have installed the SSRS Data Connector. I also created a report that uses filtered views and uploaded the report to CRM. I now created a custom user in Active Directory, added the user to CRM and gave the user the CRM System Administrator role.
In SQL Server Reporting Services, I scheduled the report to run as the custom user I had created earlier and noticed the report ran but returned no data. The same report when run with my credentials returned data.
After validating that the CRM role and SQL credentials for the custom user were the same as mine, I gave the report one more try but still no data. After additional researching and digging around and with the help of the genius minds around me, we finally found the issue:
The report I created used Filtered Views and returned pick-list text values. In CRM 4.0, Filtered Views when joining to the StringMap table, not only join to the attribute value, attribute text and objecttypecode but also to the Language Id as given below.
//Snippet of the FROM Clause of the Account Filtered View
SELECT * FROM dbo.Account a
LEFT OUTER JOIN dbo.SystemUserBase AS u
ON u.SystemUserId = dbo.fn_FindUserGuid()
AND u.IsDisabled = 0
LEFT OUTER JOIN dbo.UserSettingsBase AS us
ON us.SystemUserId = u.SystemUserId
LEFT OUTER JOIN dbo.StringMap AS sm
ON sm.AttributeName = 'accountcategorycode'
AND sm.ObjectTypeCode = 1
AND sm.AttributeValue = a.AccountCategoryCode AND sm.LangId = us.UILanguageId
The above statement returned no data as the UserSettingsBase table row for my custom user had Language Id set to 0(default) while the StringMap wanted 1033 as the Language Id.
The Language Id is one of the values that get’s set the first time the user logs into CRM and since my custom user had never logged into CRM, that value was never updated to 1033.
Once I logged in as the custom user, Voila – the report started to display data.
-
-
When installing CRM 4.0 (or upgrading from 3.0) in an environment where SQL Server, SQL Reporting Services and CRM will all be on separate physical machines, you must use the Microsoft CRM Data Connector to bypass authentication issues. Once you’ve done this, your servers will all be able to communicate without issue and your reports will work swimmingly!
Well, almost. Recently, I encountered two separate instances (a new install and an upgrade, both using the Data Connector) where we had run all of the installs without any problems, but attempts at running any reports lead to the dreaded "Page Cannot Be Displayed" error.
In one case, the event log on the SQL Reporting Services server had several security audit failures. In there other case, there were no errors to be seen. However, both situations were the result of our Report Manager not being properly configured.
Follow these steps to verify that yours is configured correctly and, hopefully, save yourself some time.
- Open up Report Manager (http://SRSServer/Reports)
- Click on OrgName_MSCRM
- On the right-hand side, on the toolbar, click Show Details
- Click on the 4.0 folder
- Then locate and click on MSCRM_DataSource
- Verify that Connection Type is set to "Microsoft CRM Data Extension" and Connect using: is set to "Credentials supplied by the user running the report"
- Click Apply
-
-
If you have tried creating a “1:N” relationship between a system entity and custom entity with the "Type of Behavior" property set to “Parental”, you most probably have also gotten an error when you try to save the system entity after updating its parent.
Let’s consider a Contact entity and a custom entity called Specialization. The relationship between Contact and Specialization is a “1:N” relationship with the "Type of Behavior" property set to “Parental”. Contact being a system entity already has a “1:N” relationship with the "Type of Behavior" property set to “Parental” with the Account entity.
So when you try to update the Contact's Parent Customer attribute and save, you are re-parenting the Contact. Since you have a relationship with "Type of behavior" set to “Parental” between the Contact and Specialization, CRM tries to re-parent the Specialization record with the updated Account object which it doesn't find. Hence the "no attribute" error.
To fix the issue, change the relationship between the Contact and the Specialization to “Configurable Cascading” and set the Re-Parent property to "Cascade None"; Save and Publish and your all set.
Now if you try to re-parent the Contact, CRM won’t try to re-parent the specialization record since the Re-Parent property is set to "Cascade None".
-
-
One of the best ways to improve a client's business is to keep users better informed and up-to-date on the information provided by CRM. A workflow could be created (and maintained) to send out an email to the appropriate parties when a specific event happens (create, update, delete of an entity), but what if we could go one step further and provide the same up-to-date information without emails (and maintaining who gets what) or without the need for a user to look in CRM? What about using an RSS feed?
Thanks to a very useful tutorial provided by Jeff at uberasp.net, creating an RSS feed for CRM can be done in a matter of minutes. For a very quick crash course in XML and the syntax for RSS, see http://www.w3schools.com/rss/rss_syntax.asp .
Say I'd like to create an RSS Feed for a specific entity in CRM. Whenever a new record is created for this entity, I want to see it in my RSS Feed. For this example, I created a custom entity in CRM called "new_rssfeed". The only attribute I added to new_rssfeed was an ntext field called "new_description" which will contain text describing the new record. After publishing my new entity type, I opened up Visual Studio 2005 and started a new ASP.Net Web Site. I renamed the Default.aspx file generated by VS to "RSS_Feed.aspx" and changed the code to the following:
//RSS_Feed.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="RSS_Feed.aspx.cs" Inherits="_Default" EnableViewState="false" %>
<%@ OutputCache Duration="300" VaryByParam="none" %>
Yup, that is all you should see in your .aspx file. No need for any html tags or DOCTYPE declarations. What will happen is that when a user navigates to the RSS_Feed.aspx file, the Page_Load event will generate a stream of XML code which the web browser will interpret as an RSS feed. So there is no need for any HTML.
Within the code-behind file, RSS_Feed.aspx.cs, I added the following code to generate the XML for the feed within the Page_Load event. You can use this code as a template for your own feed.
//RSS_Feed.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
Response.Clear();
Response.ContentType = "text/xml";
XmlTextWriter objX = new XmlTextWriter(Response.OutputStream, Encoding.UTF8);
objX.WriteStartDocument();
objX.WriteStartElement("rss");
objX.WriteAttributeString("version","2.0");
objX.WriteStartElement("channel");
objX.WriteElementString("title", "Practice CRM RSS Feed");
objX.WriteElementString("link","http://localhost:5555/RSS/RSS_Feed.aspx");
objX.WriteElementString("description","Live, up-to-date information coming from CRM!");
objX.WriteElementString("copyright","(c) 2008. All rights reserved.");
objX.WriteElementString("ttl","5");
SqlConnection objConnection = new SqlConnection(ConfigurationManager.ConnectionStrings["crmConnectionString"].ToString());
objConnection.Open();
string sql = "SELECT TOP 10 new_name, new_description, new_rssfeedid, createdon FROM new_rssfeed ORDER BY createdon DESC";
SqlCommand objCommand = new SqlCommand(sql, objConnection);
SqlDataReader objReader = objCommand.ExecuteReader();
while (objReader.Read())
{
objX.WriteStartElement("item");
objX.WriteElementString("title",objReader.GetString(0));
objX.WriteElementString("description",objReader.GetString(1));
objX.WriteElementString("link", "http://localhost:5555/MicrosoftCRM/userdefined/edit.aspx?id=" + objReader["new_rssfeedid"].ToString() + "&etc=10008");
objX.WriteElementString("pubDate", objReader.GetDateTime(3).ToString("R"));
objX.WriteEndElement();
}
objReader.Close();
objConnection.Close();
objX.WriteEndElement();
objX.WriteEndElement();
objX.WriteEndDocument();
objX.Flush();
objX.Close();
Response.End();
}
Notice the bolded text within the code. These are snippets that will differ in your code. For my RSS feed, I gave it the title of "Practice CRM RSS Feed". The link element is for the URL used to get to the aspx file. For my connection to CRM, I simply created a web.config file with a connection string to my CRM DB. Throw in your own custom SQL Query to grab the necessary info to populate the "title", "description", "link", and "pubDate" for the feed <item> element. The above code, in a nut shell, will grab the 10 most recently added New_rssfeed elements and format them for the feed. I built and published the web site project and the last thing to do was configure IIS to make the feed accessible.
In IIS, all that I needed to do was create a new virtual directory with the alias "RSS" under the Microsoft CRM web site and point it to the folder with the compiled web code. It automatically saw the web.config file, so no other adjustments had to be made. Do an IIS reset and navigate to the aspx page. You should see a basic page with the feed title and a description of how to subscribe to the feed. You will also see the feed articles listed below and search options to the right (I used IE7 -- other browsers may render differently or re-direct to an RSS Reader like Google Reader).
Example of RSS Feed rendering in IE7 (click to view larger image)

Just think of what you could use this for! You could integrate workflows and plugins with an RSS feed in order to provide up-to-date info on what's happening in CRM to other users (or anyone within the local network). Inform sales people of new opportunities and leads, give executives updates by the minute as opportunities close and new ones come in. Create one generic feed and register a plugin for multiple actions which could generate a variety of updates to the feed. You could even create multiple feeds/aspx files and give users the option of how much/ little they'd like to get updated on. We could even throw in a couple parameters like entity type and GUID and we've got an RSS feed for one specific record in CRM.
I merely scratched the surface of RSS (you can add images and other content as well), so be creative and think of how you might be able to use this to keep users (and developers) better informed of what's going on in CRM.
-
-
I've mentioned in a previous post how to add an I_Frame to a related entity: http://crowechizek.com/cs/blogs/crm/archive/2008/03/18/adding-an-i-frame-that-contains-a-view-of-related-entity.aspx. The steps mentioned work for any entity that has a 1:N or N:1 relationship in both CRM 3.0 and now the new CRM 4.0 (Titan). As you all know, Titan now has the ability to create N:N relationships! With any new feature comes some new challenges, but not to worry, you can add an I_Frame for N:N related entities. Thanks to a user who posted a comment on my blog article, I did a little digging and found that an additional parameter is needed in the url.
The additional parameter is shown in red and has been added to the original code from my other post: var urlAct = ""; urlAct = "areas.aspx?oId=" + crmFormSubmit.crmFormSubmitId.value + "&oType=" + crmFormSubmit.crmFormSubmitObjectType.value + "&security=" + crmFormSubmit.crmFormSubmitSecurity.value +"&tabSet=areaActivityHistory" + "&roleOrd=2";document.getElementById('IFRAME_History').src = urlAct;
Although I don’t have confirmation of what this parameter is, I believe it may stand for "Role Ordinal." If you look at the definition of the word "ordinal," it means to define the order or succession of something. This parameter appears to define which side/order of the N:N relationship to display. In the example above, the value is "2," which represents which side of the relationship you want to view. So if you create an N:N relationship say from the Account entity, and you're asked to fill in the "Other Entity" section, that would represent the variable "2." Another way to look at it is, if you're on the Account form, and you want to create an I_Frame pointing to the related entity of the N:N relationship, then the "roleOrd" is 2. The best way to find the value of this parameter is if you view the source of the page you're on, do a find for "roleOrd," and see what the value is for the related entity.
Either way, I've seen this example work. If anyone has any comments on this parameter, please do comment. Thank you!
-
-
If you have just completed an upgrade of your CRM system from 3.0 to 4.0, you might have discovered that your 3.0 Callouts are no longer working properly. This can be a very annoying problem, as most organizations do not want to upgrade all of there server side code right away, and need it to work immediately as promised. One of the simplest ways to debug this issue is to make sure that the Microsoft.Crm.Platform.Callout.Base.dll has been registered in the GAC during the upgrade process. If this wasn't successful, all of your 3.0 callouts will fail. Often with cryptic and unexplainable error messages. If you see that this dll is not registered in the GAC, simply register it and run an IISReset. Then retest your code. I would be willing to bet that this solves your problem.
The assumption to all this, of course, is that the callouts were working properly before the upgrade!
-
-
The default attachment file size limit in Microsoft Dynamic CRM 4.0 is 5 MB. There is good reason for this - as a general rule you should be placing some restrictions on the amount of file data that can enter CRM so that the database can maintain a reasonable size and so that performance is optimized. However, your business may find the need to increase this size a little in order to handle larger file attachments. Here are the instructions to increase the file size limit to 10 MB. You can go larger than this, but pay close attention to the table size and performance over time as you want to keep CRM running as well as possible. Note - even though the System Settings option looks like this it would apply to email attachments only, it does apply to "notes" type attachments as well. Finally, this procedure to change the max attachment size is not an officially published recommendation, so use this at your own risk. How to increase the max attachment size in CRM 4.0:
1. Open the application web.config (C:\Inetpub\CRM\web.config).
2. Locate the <httpRuntime> key within the <system.web> element and change the values to the following:
<httpRuntime executionTimeout="9999" maxRequestLength="10240"/> 3. Locate the <httpRuntime> key within the <system.web> element of the <location path='MSCRMServices"> element, and change it to the following:
<httpRuntime maxRequestLength="10240"/> 4. Save and close the web.config.
5. Open the CRM web application (http://crm).
6. Navigate to Settings | Administration | System Settings.
7. Click the E-mail tab.
8. Change the maximum file size (in kilobytes) field to 10240.
9. Click Ok to save the changes.
10. Perform IISReset.
-
-
Depending on your company’s size and installed number of users, you may or may not need a dedicated CRM admin. Microsoft Dynamics CRM is a product that lends itself to a power user for day to day maintenance and administration. However, if you have a larger number of users, say greater than 200, and especially if these users are spread out across geographic regions or branches, have independent needs, or a large amount of data to manage, then a full time admin may be your best bet.
But what should you look for in a CRM admin? It can be a challenging position to define. On the one hand, you need someone who can handle the business requirements, managing scope, timelines, and user expectations, but also someone who can deliver much of the work or coordinate the various technical departments in order to maintain and modify the system along with the growing needs of the business.
In essence, you need someone with a 50/50 mix of business and technical skills.
In particular, the ideal CRM admin should be able to:
· Meet with user groups (departments) to understand and define requirements
· Coordinate solutions and resolve differences among the departments
· Schedule resources and maintain timeline and budget
· Be able to perform system configuration work
· Understand what each area of the system offers and a basic understanding of how it works: sales, customer service, and marketing functionality, workflows, duplicate detection, and the Outlook client, to name a few
· Understand the core architecture of CRM and server topology: web servers, SQL server
· Keep up with the latest CRM industry news, Microsoft Dynamics CRM news, and community newsgroups for the latest information and patches
· Be an advocate for CRM within the company
Big bonus points for any candidate that can also:
· Program Microsoft Dynamics CRM using the SDK
· Write SQL Reporting Services Reports
· Write complex and other data mining queries against the system
· Write client-side JavaScript code
So, the next question is – how to find such a person? While this can be a difficult task, it is not impossible. Here are a few suggestions to get you going:
· Hire from Within – Hiring from within means you don’t have to train that person on the core business and begin to use them more immediately. Often times the challenge and visibility that comes from being the CRM “go to” person benefits the employee by increasing their value and security within the organization
· Consult to Hire – If you don’t have the skills on the ground to get going, consider hiring a consultant with the option to hire after a fixed period. This is a great way for both parties to “try each other out” before making a final decision.
· Place Ads on All the Major Boards – Be sure to be honest about the skills that are needed. Conduct technical screens on all candidates and find out their mix of business / technical skills.
· Check with Your Implementation Partner - Often times consulting companies and candidates are not a good match due to the high travel commitments required at consulting companies, even though the candidates skill set is ideal for CRM. Check with your implementation partner to see if they can pass along some resumes of candidates who may still be looking for a position. And lastly…
· Don’t Give Up! The right person is out there. It’s just a matter of searching in the right places, being careful about the skill set balance, and integrating that person into your organization.
-
-
When upgrading a CRM 3.0 implementation using host headers, a tricky little bug may occur that is very difficult to diagnose. The bug exists within the actual installation package of CRM 4.0, where the installation will use the machine name of the CRM server instead of the host header name. So the former address of http://<hostheader>/ will now be replaced with http://<servername>/, which of course doesn't exist.. What is more interesting, and what causes this to be hard to troubleshoot, is that when this happens the web UI will operate just as it should after the upgrade. You will be able to type in http://<hostheader>/ and it will direct you to your upgraded 4.0 implementation. Where CRM will "break" is when you attempt to run workflow's or configure the Outlook client. At this point, it will throw an error that states that the CRM server cannot be reached, and that it may be down.
The fix for this is very straightforward, although unsupported since it requires direct updates to the MSCRM_CONFIG database. Simply open up the DeploymentProperties table within this database and change the entries for AsyncSdkRootDomain, ADSdkRootDomain and ADWebApplicationRootDomain to reference your host header. Or, if you don't like making manual modifications to your database, you can run this script:
USE MSCRM_CONFIG DECLARE @HostHdr VARCHAR(250) SET @HostHdr = 'hostheader' Update DeploymentProperties SET NVarCharColumn = @HostHdr WHERE ColumnName = 'AsyncSdkRootDomain' Update DeploymentProperties SET NvarCharColumn = @HostHdr WHERE ColumnName = 'ADSdkRootDomain' Update DeploymentProperties SET NvarCharColumn = @HostHdr WHERE ColumnName = 'ADWebApplicationRootDomain' GO
Just change the value of the @HostHdr variable to whatever you need it to be, and run the script.
After that, all you need to do is run an IISReset, and restart the CRM Async service and you will be good to go. As a friendly reminder, this is unsupported and should be considered informational only.
-
-
There is a great blog by Ronald Lemmen regarding hiding and showing fields based on Security Roles for CRM 3.0 (http://ronaldlemmen.blogspot.com/2006/05/finally-there-show-and-hide-fields.html). Unfortunately, that code does not work for CRM 4.0 as the SystemUser web service is no longer available (or at least I couldn’t find it). So after much digging and fusing some of Ronald’s code, here is what I found.
In CRM 4.0, the “WhoAmI” method can be called using the CRM Service Execute method. We first create an xmlhttp object and using the “Post” method specifies the request to be handled synchronously. We then create the request object and using the xmlhttp send method retrieves the response. The response can be accessed using xmlhttp.responseXML and can be loaded into an XML DOM object (xmlDoc). The response xml returned contains the system user id and the business unit id associated to the system user. Once we get the user id, we can use the UserManager web service and use the GetUserRoles method to retrieve all the security roles that exists in CRM. All the roles that the system user is a part of will have a ‘checked=true’ value. We then check if the current user has the role we are validating against and based on the result hide/show the certain fields.
Below is the code that would need to be placed in the entity’s OnLoad Event. In our case, I am trying to hide the section with the Estimated Revenue field on an opportunity for all CSR role users:
//Based on the role of the user logged in, hide the revenue tab on the opportunity if(currentUserHasRole('Customer Service Representative')) { crmForm.all.estimatedrevenue.parentElement.parentElement.parentElement.style.display='none'; } } catch(e) { alert("There was an error with this field\'s customized event\u002e\n\nField\u003a crmForm\n\nEvent\u003a onload\n\nError\u003a " + e.description); } } }
function getUserId() { try { var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); xmlhttp.open("POST", "../../mscrmservices/2007/crmservice.asmx", false); xmlhttp.setRequestHeader("Content-Type", "text/xml; charset=utf-8"); xmlhttp.setRequestHeader("SOAPAction", "http://schemas.microsoft.com/crm/2007/WebServices/Execute"); var soapBody = "<soap:Body>"+ "<Execute xmlns='http://schemas.microsoft.com/crm/2007/WebServices'>"+ "<Request xsi:type='WhoAmIRequest' />"+ "</Execute></soap:Body>"; var soapXml = "<soap:Envelope " + "xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' "+ "xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' "+ "xmlns:xsd='http://www.w3.org/2001/XMLSchema'>"; soapXml += GenerateAuthenticationHeader(); soapXml += soapBody; soapXml += "</soap:Envelope>"; xmlhttp.send(soapXml); xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); xmlDoc.async=false; xmlDoc.loadXML(xmlhttp.responseXML.xml); var userid = xmlDoc.getElementsByTagName("UserId")[0].childNodes[0].nodeValue; return userid; } catch(e) { return null; } }
function getUserRoles(userId) { try { var command = new RemoteCommand("UserManager", "GetUserRoles"); command.SetParameter("userIds", "<guid>" + userId + "</guid>"); var oResult = command.Execute(); if (oResult.Success) { return oResult.ReturnValue; } } catch(e) { return null; } }
function userHasRole(userId, roleName) { var hasRole = false; result = getUserRoles(userId); if (result != null) { var oXml = new ActiveXObject("Microsoft.XMLDOM"); oXml.resolveExternals = false; oXml.async = false; oXml.loadXML(result); roleNode = oXml.selectSingleNode("/roles/role[name='" + roleName + "']"); if (roleNode != null) { if (roleNode.selectSingleNode("roleid[@checked='true']") != null) { hasRole = true; } } } return hasRole; }
function currentUserHasRole(roleName) { userId = getUserId(); return userHasRole(userId, roleName); }
function Test() { if(true) { try {
-
-
Recently at a client we had the challenge of developing a solution that would alert technical support when a case that was updated and needed tech support to look into the issue.
At first we thought workflows, but then realized we needed to create a custom entity that would store all of the paging information for the tech support to look at. We also needed to page different lists of people based on the escalation level, escalation frequency, day-night sift as well as the time the tech support were being paged. Oh wait I’m not done – we also needed to store all the levels reached and paging times etc in our custom entity and stop paging if tech support was already looking into the issue. We also had to have the correct lists paged based on what department of the firm the account/case belonged to.
We started off by creating a custom entity that would store the different tech support people. We then created another entity to store the different escalation levels the tech support people belonged to as well as the day-night shift information. We then created another custom entity to store the different escalation groups and the department those groups to would be responsible for (more like a profile). We needed to link the escalation profiles to the account/case since each belonged to different departments as we could have multiple profiles within a department. For this, we created another custom entity that stored the account, the department and the profile. The last custom entity we created was one that would stored the information regarding the case, account, escalation groups and time when the actual page was sent.
Next we created a create/update post callout method for the case entity that would validate if the user wanted to page tech support. In the callout we had to check if a page had already been sent and if not, not to create a new request. If the page had not been sent, the callout created the custom entity to store all the information regarding the case, account and escalations information like escalation lists, timing etc.
Lastly, we created a windows service that looked for the custom entity that had all the paging information and checked if the page had been sent or needed to be sent as well as if it was already being worked on by the tech support person. If the escalation time was reached, the service would check who was on the next escalation level as well as the day-night shift time and programmatically send an email(page) to the correct list of people and update the custom entity to reflect the most recent page.
Once the tech support person recevies the email and gets ready to work on the case, the tech support person accepts the request and the custom entity gets updated so that no more pages are sent.
More Posts Next page »
|