Skip navigation
All Places > Developer > Blog
1 2 3 4 Previous Next


215 posts

Sugar Fall '19 release is officially live! There's a huge buzz around our offices for this release - it's very exciting! Fall '19 brings an updated Portal experience as well as a few other features and fixes.


We recently held a webinar with an overview of what is in the Fall '19 release. If you missed it, watch the recording here or view the slides from this post. Note: Sugar 9.2 (Fall '19) is a cloud-only Sugar release. On-premise customers must wait until Sugar 10.0 (Spring '20) to obtain the feature enhancements provided in this release.


Here's the TL;DR for those of you looking for a quick list:

  • Portal changes:
    • Header and footer UI changes
    • Mega menu configurability
    • Metadata customization
    • New fields in Contacts module
    • Portal users are now able to use Preview to view records
    • Cases, Notes, and Bugs now show in Portal by default
    • Ability to designate/identify the source of a case has been added
    • Knowledge Base dashlet added to Portal home
    • Administrators can now choose to enable "case deflection"
    • Portal FilterView and PortalListTop UI components were deprecated
    • Portal users can now search for answers to their own questions
    • Field display changes to Portal views
    • It is no longer possible to view PII from the Portal User Profile screen
    • 3 new Portal dashlets have been added
    • Improved Portal user signup
    • Admins can configure password reset options (phone, email, url)
  • Library updates
    • Jquery
    • jQuery Migrate
    • moment.js
    • Bootstrap library components
  • Business Centers Module now added to Sugar Sell


For details on everything in this release, check out our other Summer '19 resources:

Hello Sugar Developers!


Fall is upon us and we have lots of things to share. We want to make sure you are ready for the Sugar Fall '19 release, so we're hosting two webinars just for you!


What we will be covering:

Some big changes that are likely to impact you this fall are:

  • Portal updates and improvements
  • Business Centers module has been added to Sugar Sell
    • Associates Leads with a business center to keep track of business hours per location. Using SugarBPM, lead SLAs can be met by automatically following up within a time measured in business hours
  • Javascript Library and Bootstrap component updates


We will also spend some time on:

  • Customizing the new Portal
  • Addressing common questions about new SugarCRM product lines
  • More best practices for developing for the Cloud


Webinar Information:

We are holding two sessions to accommodate various geographical locations.On the registration page, you will have the choice of ONE of the following times.


Monday, September 23rd 4:30 - 5:30 PM PT


Tuesday, September 24th 7:00 - 8:00 AM PT


Register Now!

We will be posting the webinar recordings to the Sugar Community for those who are unable to attend the live sessions.

Hi, my name is Julian Haresco and I am a Software Engineering Intern at SugarCRM. I am going to be a rising senior at Purdue University majoring in Computer Science with a focus in Machine Learning and Software Engineering. This summer, I was given the opportunity to integrate Amazon’s Beta EventBridge API with Sugar for SugarCRM to become one of Amazon's ten launch partners for the EventBridge.


What is Amazon EventBridge?

In case you haven’t heard, Amazon released a new product for its cloud services called Amazon EventBridge. This service is a new addition to the vast array of services offered within Amazon Web Services (AWS) but comes with a very special feature that I believe makes it stand out from other products offered by Amazon’s cloud service. EventBridge is unique as it allows you to utilize a third-party SaaS system to send CloudWatch Events to AWS. The biggest benefit of this product is the freedom it offers to customers. Since the Event Buses and sources are customizable based on region, they can view the events in their desired location and then have them interact with other AWS resources easily. Furthermore, prior to EventBridge, all AWS CloudWatch Events could only be triggered by another resource within AWS. So allowing them to connect to an external SaaS system simply allows for AWS to be more usable than ever before with data external to AWS.


Amazon has partnered with various SaaS companies to set-up what they are calling Partner Event Sources. These are SaaS systems with EventBridge Partner Event Sources integrated into their systems already for customer use. SugarCRM Inc. is one of the ten initial AWS EventBridge launch partners including Symantec, Zendesk, and SignalFx. For Sugar, this pre-installed integration builds a timeline within AWS based on the modules and logic hooks the developer desires. Empowering customers with a real-time log about how the records and relationships within their system are changing with every event sent.


Here’s how I did it

To meet these needs, a new administration module that is installed via a module loadable package was created named EventBridge Logic Hooks. Within this module, Sugar will automatically connect, or create, the internal “Partner event source” based on how the customer fills out the fields when creating a new record for this module. However, the values within the fields will need to meet the requirements outlined in our support documentation for Amazon EventBridge. This module then automatically creates a Sugar logic hook that will send an event to EventBridge using the Partner Event Source to the AWS account they provided once the specified module triggers the logic hook.



On the Amazon side, the EventBridge Console will automatically display the “Partner event source” with the same name displayed on the record created with Sugar. These event sources can then be attached to an Event Bridge by following Amazon’s instructions. Now our customers can attach the event source to the Event Bus. This allows them to target resources that best suit their needs.



How do developers get involved?

Developers who want to experiment with Sugar’s integration of EventBridge can download the module loadable package from SugarExchange and follow the instructions outlined with our support documentation for Amazon EventBridge to install the module. From there, developers should be able to effectively create and set-up Partner Event Sources and connect them to an EventBus within their AWS account. 


NOTE: This is a beta version so there are improvements that could be made. For example: The operations to Event Bridge are synchronous which may cause additional latency in save operations for enabled modules.


What has been our experience?

Amazon EventBridge has been incredibly easy to use in terms of creating, editing, and setting up the Partner event source within Sugar. As a developer, the documentation is clearly laid out and extremely helpful in finding the answers to any questions about configuring EventBridge within a SaaS system like Sugar. Furthermore, the EventBridge Console makes a clear distinction between a Partner event source and one I create on my own. This set-up is incredibly  intuitive and easy to use, providing a seamless set-up process from within Sugar to the AWS EventBridge Console on the customer’s side.


This project was just the beginning. AWS EventBridge opens up great possibilities for integration. I'll continue using it and looking for new ways to leverage this system. I hope you will too. So, please, take a look at AWS EventBridge. Connect it with Sugar. Then, tell us about your experiences in the comments.

We recently held a webinar on How to write code for SugarCloud. At the end, we gave a summary of some of the Dos and Don'ts for working with SugarCloud.


With more and more customers utilizing SugarCloud products, I thought it would be a good idea to expand on some of the basic best practices when developing for SugarCloud. As Sugar's cloud-based product line evolves, I will add more items to this list.


When developing for SugarCloud:

use custom code when configuration will do just fine.

The ability to write custom code for Sugar is a huge benefit. It isn't, however, the best solution for all situations. Very often your problem can be alleviated by simply using the configuration tools that Sugar provides in its admin console. Manipulating a configuration in the system is typically a safer choice as there is no concern with upgrade compatibility.


have direct filesystem or DB access.

SugarCloud is a shared environment. Any changes made to the filesystem could impact other customers.


use blacklisted classes, functions, or file types.

In order to maintain the integrity of the standard Sugar functionality when we upgrade a customer instance and limit any negative impact our upgrade has on the customer's modifications, all instances hosted on Sugar's cloud service have package scanner enabled. Here is a blacklist of cases that will cause the package scanner to fail.


perform load or pen testing without permission of Sugar Support.

SugarCloud is a shared environment. An unscheduled load test may cause performance issues with other customers' instances. You must obtain Sugar Support's permission so that they may make the proper adjustments to ensure no other instances are affected by your tests.


introduce performance or security issues with your code.

For the safety and security of your users, it is never wise to introduce performance or security issues into your code. This is especially true when working in a shared environment so as not to affect other customers' user experiences.


disable or circumvent package scanner.

Package scanner is enabled on all cloud instances to ensure no security violations are introduced.


allow an outbound HTTP connection to last longer than 1 second.

SugarCloud is a shared environment. Long connections can have a performance impact on your users as well as the users of other customers.


abuse the job queue with a multitude of long running jobs.

SugarCloud is a shared environment. Long running can have a performance impact on your users as well as the users of other customers. If you load the queue with too many long running jobs, the rest of the jobs awaiting their turn will be affected


abuse the REST API with more than 20 requests per second.

SugarCloud is a shared environment. Too many requests can have a performance impact on your users as well as the users of other customers.


upgrade to every new release.

Sugar Sell and Sugar Serve operate on a quarterly update cycle while Sugar Market is updated approximately every two weeks. Each update will include new improvements or fixes from the previous version. It is important to keep up-to-date on these upgrades to minimize the number of things that will need to be tested. 


test before you deploy!

It is always better to find any issues in a test environment prior to deploying live. If there are issues or incompatibilities after a change, these should be caught and addressed before a user runs into a problem.


Want to learn more? Don't miss the webinar recording.

In response to the recent evolution of the SugarCRM product line, we’ve compiled a list of answers to some common questions that we have received from the developer community about our new products. This FAQ will be a living document, so please post any additional questions in the comments section and we will do our best to address them here.

Sugar Professional and Enterprise customers: 

If you are an existing customer of Sugar Professional or Sugar Enterprise then nothing has changed for you. If you are in our cloud, you will still get new features on a quarterly basis. If you are on-premise, you will still get new features on an annual basis.

QuestionSugar MarketSugar SellSugar Serve
Will it be available On-Premise?No. Sugar Market, Sugar Sell, and Sugar Serve are available via cloud only and are not available for on-site deployment.
Can we write code customizations for it?The Sugar Market platform does not support direct code customizations. It does, however, have REST APIs and other tools to enhance your development.

Yes, Sugar Sell and Sugar Serve are based on the Sugar Enterprise platform which supports code customizations. You can use Module Loader to install code customizations for Sugar Serve and Sell. Since Serve and Sell are built on Sugar Enterprise, use the ENT flavor in your package manifests.

How can we download instance backups for local development and test?No, Sugar Market is a multi-tenant application. There is no concept of local development.Yes using Backups module.
Can we get data backup?Yes, by exporting a report.Yes using Backups module.
Can we access development builds?We are working toward a solution for this.There is a Developer Builds space in the SugarCRM Developers community. We will post development builds here for each release.
Will Sell/Serve/Market use the same platform as Sugar Enterprise?Sugar Market is a unique platform.Sugar Sell and Sugar Serve are built on the Sugar Enterprise platform.
Will Sell/Serve/Market be connected to the same database, or will they be separate instances connected via API?At this time, Sugar Market utilizes an independent database. Sugar Market integrates with Sugar Sell/Ent/Pro out of the box.A single SugarCloud instance and database can have both users of Sugar Sell and Sugar Serve using it at the same time.
Where can I find more specific info about the divergence between Sugar products?The differences between the SugarCRM License Types are outlined in the User Management section of the Sugar Enterprise 9.1 Administration Guide.
What resources are available if I have more questions?Sugar Market DocumentationSugar Sell DocumentationSugar Serve Documentation
How often will Sugar products be updated?

Sugar Market operates on a continuous update cycle, with releases approximately every two weeks.

Sugar Sell and Sugar Serve operate on a quarterly release cycle (every three months).

Sugar Summer '19 release is officially live! There's a huge buzz around our offices for this release - it's very exciting! Summer '19 introduces brand new Sugar products as well as many enhancements for existing Sugar Professional and Sugar Enterprise customers.


We recently held a webinar with an overview of what is in the Summer '19 release. If you missed it, watch the recording here or view the slides from this post. Note: Sugar 9.1 (Summer '19) is a cloud-only Sugar release. On-premise customers must wait until Sugar 10.0 (Spring '20) to obtain the feature enhancements provided in this release.


Here's the TL;DR for those of you looking for a quick list:


  • SugarIdentity service is out of beta. SugarIdentity is a set of user authentication and access management microservices that will improve how we manage Sugar cloud users today. It offers improved OAuth 2.0 support, leverages OpenID Connect, and supports SAML Web Single Sign On (SSO) with the MS Outlook Plug-In. Read more about SugarIdentity in our post called What you need to know about the new SugarIdentity service! All new SugarCloud customers in the Americas, including those customers of our new Sugar Sell and Sugar Serve products, are using SugarIdentity today.
  • Sugar products now support TLS encryption for LDAP single sign-on.
  • A new field on user records, License Type, has been added to allow administrators to grant each user access to one or more products including SugarCRM's newest offerings, Sugar Sell and Sugar Serve.
  • NEW PRODUCTS!! We are very excited to announce 3 new products:
    • Sugar Market is a rebranding of Sugar's recently-acquired marketing automation solution, SalesFusion.
    • Sugar Sell is our award-wining sales automation solution.
    • Sugar Serve is Sugar's new customer engagement center solution.
  • The new SugarCloud Insights page allows administrators to easily monitor their instance's database and file system storage usage, license usage, as well as gain access to PHP error logs and access logs.
  • Shareable dashboards now include custom user-created filters.
  • Tile View : For cases, tasks, and opportunities, a new view has been added that displays records as tiles in a familiar interactive, drag-and-drop interface.
  • Bug and Case bean classes now extend \Issue instead of \Basic class.
  • A new direction field has been added to the Emails module. The possible values are inbound, outbound, internal, unknown.


For details on everything in this release, check out our other Summer '19 resources:

We intend to disable support for TLS v1.1 and older in the SugarCloud on November 8, 2019 February  1, 2020. This action is consistent with the rest of the industry. It may impact some Sugar integrations that connect to the SugarCloud. If you are hosting Sugar on-site, you should consider taking similar steps to disable TLS v1.1 and earlier on your web servers.


Read on to learn more.

TLS/SSL Vulnerabilities

The SSL (“Secure Sockets Layer”) protocol was initially invented by Netscape back in the mid-1990s as a method for securing communications over a computer network. This protocol provides the “S” in HTTPS which is used to secure all HTTP traffic to Sugar web servers. As you might expect with 25 year old security technology, there’s been quite a few revisions and improvements to the original concept over time. In fact, SSL v3.0 came out in 1996 which was only a couple years after SSL itself was first invented. SSL was later succeeded by TLS (“Transport Layer Security”) which itself has seen several iterations.





SSL 1.0



SSL 2.0


Deprecated in 2011 (RFC 6176)

SSL 3.0


Deprecated in 2015 (RFC 7568)

TLS 1.0


Deprecation planned in 2020

TLS 1.1


Deprecation planned in 2020

TLS 1.2


TLS 1.3


Courtesy of Wikipedia


With most technology, the penalty for not adopting the latest and greatest is mostly FOMO (“fear of missing out”). But cryptographic protocols are used for target practice by white and black hat wearing security researchers the world over. This means that using out of date cryptographic protocol compounds FOMO with FOLE (“fear of losing everything”).


The value of a TLS/SSL protocol is inversely proportional to the number of holes that have been punched into it. Some of these holes are exploits that go by the name of POODLE and BEAST. At the same time, the industry has been continuously adding better and stronger encryption protocols in response.


The industry is dropping support of old TLS versions

SSL is REALLY old, so hopefully nobody is still using this. However, there is still plenty of code out there using older versions of TLS. The PCI Data Security Standard requires all connections to use TLS v1.1 or higher while strongly recommending TLS v1.2 or higher. Even the browser vendors who are loathe to drop features that could impact website compatibility (and market share) have agreed to drop support for TLS v1.0 and v1.1 in 2020.


As a result, we are considering the right time to disable support for TLS v1.1 and older for connections to the SugarCloud. This may impact some Sugar integrations that connect to the SugarCloud as we look to stay in step with the rest of the industry.


Make sure your REST API integrations are using TLS v1.2+

If you are using a modern web browser, then it is unlikely that you will run into any problems connecting to Sugar instances. However, some REST API integrations that are using old client libraries or runtimes are liable to use these older protocols. Basically, if you are running 10+ year old software in your integration then you will likely have some of these problems below.


In particular, please take extra care if you are using any of the following technology with your Sugar integration.



Preferred Runtime

Apache HttpComponents

Use latest Java 8 or greater


Use latest .NET 4.7 or greater

cURL and OpenSSL (PHP)

Use OpenSSL 1.0.x or greater (PHP 7.1 or greater)


If you aren’t sure, you can use a network analyzer to verify the version of TLS that is in use. For example, you can use tcpdump or Wireshark.


Take the following steps if you believe your integration is affected.

  • If applicable, upgrade to newer runtime environments for your integrations
    • Ex. Upgrade to Java 8 or newer or to .NET 4.6 or newer
  • Upgrade to latest HTTP client library versions
    • Ex. HttpComponents v4.4.11+ is compatible with TLS v1.3 implementation found in Java 11
  • Configure your HTTP clients to require use of TLS v1.2

How to disable TLS v1.1 and earlier for Sugar on-site installations

You will typically configure the web server with the versions of TLS/SSL that will be allowed by your Sugar instance.


For Apache, the allowed versions of TLS can be configured using mod_ssl’s SSLProtocol directive


For IIS, the allowed versions of TLS can be configured using TLS Registry Settings.


Connections using TLS v1.1 or earlier will break

Only 6% of web traffic in SugarCloud is using an out of date version of TLS. So we are moving aggressively to ensure SugarCloud will only support TLS v1.2+ in the future. 



Support for TLS versions 1.1 and older in SugarCloud will be disabled on November 8, 2019.

Updated Support for TLS versions 1.1 and older in SugarCloud will be disabled on February 1, 2020THIS IS A FIRM DEADLINE AND WILL NOT BE EXTENDED.

Hello Sugar Developers!


We often get questions about building code customizations for SugarCloud. Even experienced developers who have developed customizations for on-site Sugar installations do not know what is possible in SugarCloud. In short, Sugar Cloud does support custom code though there are some rules that need to be followed. We will dig into how write code customizations for SugarCloud in this webinar.


What we will be covering:

We will demonstrate by example (with the help of Professor M) the following topics:

  • Accessing SugarCloud Developer Builds
  • How to configure local dev environment to be similar to SugarCloud
  • Methods for managing and deploying custom code in SugarCloud
  • How to debug problems in a Cloud instance
  • Important rules to keep in mind


Webinar Information:

Join us for the live webinar:

Tuesday, July 16th 7:00 - 8:00 AM PT

Register Now!


Can’t make it? Don’t worry! We will be posting the webinar recording to this community for those who are unable to attend the live session.

SugarCRM strives to be the "No-Touch" CRMOne of the most important steps in making this vision a reality is to integrate Sugar with systems that customers uses to engage with organizations. For example, if a customer has been recently complaining about your product on your blog, wouldn't you want to know about that before talking with them?


Building a Wordpress integration


This post will explain how to import a comment from your blog (using Wordpress for this example) into Sugar as a note record related to the lead or contact who posted it. The goal of this exercise was to illustrate how to communicate from a common external content management system and Sugar. It turns out that getting the data into Sugar using REST APIs is pretty simple. It was everything else that took some thought and time.


The project started out as "send a Wordpress comment to Sugar as a note." It turned into much more than that (and has the potential to go so much further). So, here's a high level of our steps:


  • Created a Wordpress plugin
    • Plugin will record the Sugar login credentials and instance path
    • Plugin will call the Sugar OAuth REST endpoint to validate the user's credentials before allowing a save 
  • Upon submitting a comment to any Wordpress blog post, the comment data is sent to our instance of Sugar as a Note
    • Get the current logged-in Wordpress user
    • Authenticate to the Sugar API
    • Check if Wordpress user is in Sugar already (by e-mail address)
      • If so, add this comment as a Note linked to their [Account] record
      • If not, create a Lead record then create and link a Note to that record


Every CMS has its own special methods for connecting to external APIs. I chose to not use those functions in Wordpress for this exercise and simply used PHP's cURL functions. This should allow our example to be reused more easily with other applications.


The first step was to create the Wordpress plugin with a Settings page to allow a Wordpress admin to configure the integration. Our Settings page asks for Sugar user credentials, the URL to your instance of Sugar, and which version of the API your instance is using. All of this information gets stored in the Wordpress database for easy retrieval by our plugin.


The Wordpress settings page for our custom plugin


Now that we have our credentials, we will do something with them. We will create some functions that kick off when a Wordpress user adds a comment on any blog post. Wordpress has an action called "comment_post" that gets triggered after a comment is added by a user and subsequently stored in Wordpress database. We can assign a custom function to fire when that event is triggered by writing:

add_action( 'comment_post', 'send_comment_to_sugar_function', 10, 2 );


Basically, this line says any time a comment is saved to the Wordpress database, call the function called 'send_comment_to_sugar_function' with a priority of 10 and 2 possible parameters. For more information on Wordpress actions and hooks, check out the Wordpress Codex.


Now, let's write the guts for that custom function. The first thing we must do is authenticate to Sugar API. To do that, we will build the URL to the REST endpoint by concatenating the values that we stored in the plugin's settings page. This looks something like:

$api_path_auth = "/oauth2/token";
$auth_url = get_option('sugarcrm_input_url') . '/rest/v' . get_option("sugarcrm_input_api_version") . $api_path_auth;


On the settings page, I saved the values in the DB as "sugarcrm_input_url", "sugarcrm_input_api_version", "sugarcrm_input_username", and "sugarcrm_input_password". So, we can access those values with get_option(OPTION_NAME).


The oauth2/token endpoint needs parameters to return a successful authentication. Here is what we are sending:

$oauth2_token_arguments = array(
        'grant_type' => 'password',
        'client_id' => 'sugar',
        'client_secret' => '',
        'username' => get_option( 'sugarcrm_input_username' ),
        'password' => get_option( 'sugarcrm_input_password' ),
        'platform' => 'wordpress_api'


Note the "platform" parameter. This is the name you are giving to your Wordpress instance. You must go into Sugar's Admin settings to allow this platform to communicate with the Sugar REST API. The name could be anything that you like - as long as you add that same name to the Sugar API Platforms list.

Configure API Platforms page in the Sugar Admin

Now that we have our parameters to send, we need to set the cURL options. For a more detailed explanation of cURL in PHP, check out the PHP cURL manual


These are our options (pretty typical):

$auth_request = curl_init($auth_url);
curl_setopt($auth_request, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
curl_setopt($auth_request, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($auth_request, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($auth_request, CURLOPT_FOLLOWLOCATION, 0);
curl_setopt($auth_request, CURLOPT_HTTPHEADER, array(
    "Content-Type: application/json"

//convert arguments to json
$json_arguments = json_encode($oauth2_token_arguments);
curl_setopt($auth_request, CURLOPT_POSTFIELDS, $json_arguments);


That last line is where we are ensuring that we are POSTing to the endpoint and that we are sending a JSON encoded array of parameters.


Finally, we can execute the request and parse out the data that we need from the response:

$oauth2_token_response = curl_exec($auth_request);
$oauth2_token_response_obj = json_decode($oauth2_token_response);
$sugar_oauth_token = $oauth2_token_response_obj->access_token;


I originally had the function return the auth_token but I decided to also store the auth_token and the refresh_token values in the Wordpress cache so that I can grab them whenever I need them. This will ensures we aren't needlessly logging into Sugar over and over again.

wp_cache_set('sugar_oauth_token_access', $sugar_oauth_token);
wp_cache_set('sugar_oauth_token_refresh', $oauth2_token_response_obj->refresh_token);


Now that we have authenticated, we can start sending data through the Sugar REST API. Let's see if the current wordpress user is in our instance of Sugar by utilizing the global search API (/search). Since we are making a GET request, we will format our URL to include our parameters in the URL query string. I used the http_build_query function to loop through an array of parameters and construct a query string to be appended to the end of our endpoint URL. This could have been done manually.


Either way works as long as the final result resembles:


With the URL setup, we need to use cURL again. Since the settings are essentially the same for each of my requests, I wrote a single function to initialize and execute our REST calls.

function curl_it($sugar_oauth_token, $curl_url, $data = null, $ispost = false) {
     $the_response = null;
     $the_request = curl_init($curl_url);
     curl_setopt($the_request, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
     curl_setopt($the_request, CURLOPT_SSL_VERIFYPEER,1);
     curl_setopt($the_request, CURLOPT_RETURNTRANSFER, 1);
     curl_setopt($the_request, CURLOPT_FOLLOWLOCATION, 0);
     curl_setopt($the_request, CURLOPT_HTTPHEADER, array(
         "Content-Type: application/json",
         "oauth-token: {$sugar_oauth_token}"
     if ($ispost) {
          curl_setopt($the_request, CURLOPT_POSTFIELDS, $data);
     $the_response = curl_exec($the_request) ;
     return $the_response;


The notable part of this is where we set the OAuth-Token or a standard bearer token. This wasn't necessary in the initial auth call.

curl_setopt($the_request, CURLOPT_HTTPHEADER, array(
    "Content-Type: application/json",
    "OAuth-Token: {$sugar_oauth_token}"


Now we should have a response back from Sugar. This response, if successful, will contain a record that has an e-mail address matching the one we sent in. From the returned record, we can grab the IDs that we need to be able to associate this comment with the returned user. We will add the comment as a note linked to the account record. In order to appropriately associate the new note, we'll send the Sugar User ID as the parent_id for the note and ensure that we are using the appropriate parent_type.


What if the e-mail address of the current Wordpress commenter can't be found in Sugar? Well then let's add them as a Lead and THEN create the new note and attach it to the newly created lead record.


What if the e-mail address is found but it is a Lead and not a Contact? Then we need to set the parent_type to "Leads" and the parent_id to the id of the Lead record. For anything else, we use the account_id from sugar as the parent_id.


Now that the plugin is doing essentially what we want it to do, there’s many enhancements we could add. The first one I threw in there was a verify button on the admin form to check if the user settings are valid. I adjusted the auth function to take the form values as parameters. That way, when we expose the function for REST calls we can pass in the values from the form BEFORE they are saved to the Wordpress database.


This button is essentially making the same authentication REST call that we are making when sending data to Sugar. I could have written the javascript to call the Sugar endpoint directly but that opens up a few issues. Firstly we would likely (I did) run into a Same-Origin policy conflict where the Sugar client doesn’t recognize and/or trust the external Wordpress domain. The other issue I saw was that I’d have to rewrite exactly what I did in the PHP for the front-end. I prefer reusable code. There were also some security issues to consider but these were the glaring problems from a strictly front-end implementation. SO, I simply researched how to turn my Wordpress functions within the plugin into additional endpoints in the Wordpress API. All it took was registering the route for the endpoint and telling it which function to call.

add_action( 'rest_api_init', 'init_rest_api' );

function init_rest_api () {
     register_rest_route( 'sugarcrm-api/v1', '/auth', array(
          'methods' => \WP_REST_Server::EDITABLE,
          'callback' => 'sugarcrm_rest_auth_validate',
          'args' => ['username', 'password', 'url', 'version']

Other tips & tricks

Much of this exercise was new to me (or I needed some refreshers). What I found was that sending the data to Sugar was not particularly difficult. The work came from deciding what to do with the information and how to handle different scenarios - like the user already being in the system as a Lead not a Contact. I spent a lot of time using the browser console to look at objects returned in the Sugar instance. I think I used this command in the console more than any other:



I would navigate to a Lead or Note record in Sugar and then run that command in the developer console to see all of the properties and values for the current module. It really helped me decide on what data to send or grab.


But not everything could be traced out on the front-end. So, Stack Overflow came to my rescue with a simple logging function I implemented in the PHP. With this function, I could spit out whatever I wanted to a local log file for debugging. If I wanted to see the contents of a response object, for example, I would write the line:

log_it($my_response, 'The object my_response contains: ');


Try it out yourself!


If you would like to use the code that was written for this article for some hands-on practice, you will need an instance of Sugar and an instance of Wordpress. I did it all locally with a Vagrant box for Sugar and MAMP for the Wordpress instance.


You don't need to install any custom code into Sugar. It uses the standard REST API and a custom API platform which can be configured easily via Sugar Admin panel.


The Wordpress integration code has been added to the SugarCRM Building Blocks git repository in the api-examples directory. Simply download and unpack the plugin files and drop them into your Wordpress plugins directory (typically at /wp-content/plugins). Now you should be able to activate the plugin in Wordpress and add your customized settings via the "Sugar API Plugin" settings menu option on the left navigation (like that custom logo icon? hehe).


Wordpress admin side navigation hi-lighting "Sugar API Plugin" option


Remember to register the platform in Sugar's admin section using the name "wordpress_api" or whatever you change it to in the code. That's it!


To try it out, you should be able to add a comment to a Wordpress post and see it attached to a record in Sugar.


Now go play! Here are some ideas for changes you can make to my plug-in example.


  • Try to add more detail to the Note created in Sugar.
  • When a comment is deleted in Wordpress, find the note in Sugar and update it.
  • Include a link to the record in Sugar that points back to the comment in Wordpress.
  • And please... share with the community what you did - no matter how minor or major.


I hope you enjoyed this article. I’ve never really thought of myself as a writer. In fact, my first job was working in an orange juice factory. But I got canned. I couldn’t concentrate.

Hello Sugar Developers!


Summer is just heating up and we have a boat load of stuff to share. We want to make sure you are ready for the Sugar Summer '19 release, so we're hosting two webinars just for you!


What we will be covering:

Some big changes that are likely to impact you this summer are:

  • Introduction of Sugar User License Types
  • The launch of SugarIdentity
  • Lots of exciting new UI enhancements including Shareable Filters
  • And much more!


Webinar Information:

We are holding two sessions to accommodate various geographical locations.On the registration page, you will have the choice of ONE of the following times.


Monday, June 24th 4:30 - 5:30 PM PT


Tuesday, June 25th 7:00 - 8:00 AM PT


Register Now!

We will be posting the webinar recordings to the Sugar Community for those who are unable to attend the live sessions.

Tell Us About Your Experience:

We'd also appreciate five minutes of your time for a short survey to tell us a bit about yourself and your experience developing on Sugar. The Developer Advocacy team is collecting your input in order to better support you in building world-class solutions that creates customers for life. And if you have further input or questions, you to reach out to us directly at


Take the Survey!

The 'idm_mode' config setting was moved out of config.php and into the database. It's now necessary to update the config table to disable this setting for a local backup. Instructions updated below.

Those who have been around a while will know that SugarCRM Inc. was built around a single product called “Sugar”. Sugar is such a part of our DNA today that we often use “Sugar” and “SugarCRM” terms interchangeably. I’m sure that many Sugar Developers out there would be surprised to learn that we sell more than just Sugar at SugarCRM!


Sugar has been good to us but the way apps were built in 2004 and how apps are developed today are much different. We’ve been thinking about how we want to build, deploy, and maintain new applications and services today and in the future. This has led us to a long term investment to develop a framework for new cloud-based services that are tightly integrated with Sugar.


The tip of the spear is a new set of identity and access management services that we call SugarIdentity. Coming to a Sugar instance near you in June 2019!


What is SugarIdentity service?


SugarIdentity is a set of user authentication and access management microservices that will improve how we manage Sugar cloud users today. Regardless of the SugarCRM products and services you are using, you will be able to manage your end users in one place. This will make life easier for Sugar administrators while allowing SugarCRM engineers and Sugar Developers to more easily integrate Sugar and other applications and services including those built by partners and ISVs in the future.


It will offer improved OAuth 2.0 support, leverages OpenID Connect, and will also address a frequent customer request to support SAML Web Single Sign On (SSO) with the MS Outlook Plug-In.


SugarIdentity also supports the concept of Service Accounts which can be used to implement secure Server to Server integrations much easier without involving end user credentials.


It also provides a new Cloud Settings user interface that Sugar administrators will use to manage end users and some subtle but important changes to end user login experience.


We plan to start on-boarding new Sugar cloud customers in some regions to SugarIdentity service in June 2019.

Frequently Asked Questions


We’ve just recently finished up our SugarIdentity Beta where we asked a handful of partners and customers to test drive the new system. We received a lot of valuable input that we used to improve these services. We also received a number of questions from Sugar Developers that we wanted to share below:


How do I know if a given Sugar instance is using SugarIdentity?

SugarConfig settings are updated in order to connect a Sugar instance to SugarIdentity services. This will be done automatically for our Sugar cloud customers. SugarIdentity does not currently support Sugar on-premise installations. In practice, you can check the public metadata REST endpoint for any given Sugar cloud instance to see if it is operating in “IDM mode”.


GET /rest/v11_4/metadata/public


The response will include:




   “config” : {


      “idmModeEnabled”: true | false






This setting will be true if SugarIdentity is in use.


How to find the Tenant ID for a given Sugar instance?

In most cases, you will not need to know the specific Tenant ID for your Sugar instance in the Sugar cloud. However, it can be useful to know if you need to login to Cloud Settings console directly.



For example, it can be used with the tenant_hint URL parameter to allow more seamless logins to Cloud Settings.{TENANT_ID}


The Tenant ID can be retrieved from a Sugar instance’s SugarConfig settings or from the public metadata API.


GET /rest/v11_4/metadata/public


The response will include:




   “config” : {


      “tenant”: “srn:cloud:iam:us-west-2:{TENANT_ID}:tenant”






The tenant config property above is an example of a Sugar Resource Name (SRN). SRNs are used to uniquely identify resources across the Sugar cloud ecosystem. You’ll see more SRNs as you adopt the new platform and we roll out more features.


How do I deploy a backup of a Sugar cloud instance that uses SugarIdentity?

If you have a backup of a Sugar cloud instance that was configured to use SugarIdentity then it will not likely work without some configuration changes. This is because your local system will not have permission to access the identity services running in the Sugar cloud.


Take the following steps to disable SugarIdentity before working with the backup.


Run the following SQL query on your local Sugar DB:

UPDATE config SET value = 0 WHERE category = 'idm_mode' AND name = 'enabled'


In a terminal, remove cache/ directory contents:


$ rm -rf [path to sugar]/cache/*


How does Users module change with SugarIdentity?

User information is now federated across SugarIdentity services and the Sugar instance Users module. When a Sugar instance is connected to SugarIdentity, there will be specific User fields that are no longer owned by the Sugar instance. For example, the user name or e-mail address will be modifiable by a new Cloud Settings user interface and not within Sugar.


Updates that are made in Cloud Settings are pushed to Sugar user records automatically via REST APIs and also at the time of each user's login. If you have customizations that write to Users module, these changes could be overwritten by SugarIdentity services.



At this time, the following Users module fields are owned by SugarIdentity services and should only be updated via new Cloud Settings user interface.


  • first_name
  • last_name
  • address_street
  • address_city
  • address_state
  • address_postalcode
  • address_country
  • email_addresses
  • phone_work
  • title
  • department
  • status
  • is_admin
  • preferred_language
  • user_name


Custom fields on the Users module are not overwritten.


What are changes when authenticating via SugarIdentity?

Ultimately, SugarIdentity will provide more options for authentication and authorization. This will be the area of biggest impact for Sugar integrations.


Web Users

When an end user navigates to a Sugar URL and they are not yet logged in they will be redirected to a login service. This login service will have a different URL than their Sugar instance. However, once logged in they will be redirected back to their Sugar instance.


REST API integrations

If authenticating using REST API, the endpoint behavior is essentially unchanged. What has changed is the format for OAuth access and refresh tokens. Instead of using UUIDs, SugarIdentity uses encrypted tokens that are base64 encoded. If you are storing access or refresh tokens, they can now be up to 255 characters long. However, there is no hard limit on their size and they may get longer over time.





What functionality or customizations are not supported when using SugarIdentity?

Much of the responsibility for handling authentication is now delegated to SugarIdentity services. This means that many customizations to Sugar’s authentication mechanisms are no longer supported.


In particular, if you have created any custom SugarOAuth2Storage* classes then these will not work when SugarIdentity is used. The responsibility for generating and managing authentication tokens is now the responsibility of our Sugar cloud service instead of the Sugar instance.


If you feel like an essential authentication feature is missing in SugarIdentity services, then please let us know by filing an enhancement request via the Support Portal.


When using SAML Web SSO, should I move my integration users to my external identity provider?

Some customers that have wanted to use SAML with Sugar have held off until the SugarCRM Outlook Plug-In supported it. For Sugar customers using the new SugarIdentity service, the Outlook Plug-In will now support SAML Web SSO for the first time.


If you’re using integration users, we recommend leaving them as local user accounts instead of moving them to your SAML identity provider. The same advice applies when using LDAP an external identity provider too. SAML Web SSO isn’t well suited for REST API integrations since it requires credentials to be entered into a browser which makes automated authentication challenging. Your SAML or LDAP identity provider should only be responsible for managing employee access to Sugar.


This is also a use case where Service Accounts will come into play. Service Accounts will allow for the separation of responsibility between regular user accounts and services accessing Sugar data for integration purposes. This is a feature we are planning to implement in the future.

Good Morning, Sugar Developers!


That's me! Gotta be festive at the holidays!

My name is Michael Shaheen and I am SugarCRM’s new Developer Advocate. I’ll be working with Matt Marum to maintain relationships between our developer community and the teams that work with the Sugar product group.


Let’s talk a bit about my background. I have been a developer since writing

10 print “Michael Rocks”
20 goto 10

to fill up the screen at the mall Radio Shack in the early 80s. Since then, I have worked for multiple companies as a manager of software development teams. I may have been managing, but I can never stop coding. I love to get into projects and solve problems. Lately that has been mostly front-end work (Javascript, React, SASS, task runners, etc), but I’m not a stranger to back-end. I spent many years coding in .NET, Java and PHP.


At home, I have a beautiful wife and 2 lovely teenage daughters. Oh and cats. We have 2 indoor and a few outdoor cats that we take care of. I also tell a lot of dad jokes (but that started before the kids).


Over the past 3 weeks, I have been learning all there is to know about SugarCRM as an organization and Sugar as a platform. I’m looking forward to talking to each of you through the Developer Community and, hopefully, in person as much as possible. From the conversations I’ve had with SugarCRM engineers, I know that they all want to put out the best quality product possible. The Developer Community is one of our top ways of gathering feedback. I aim to ensure your feedback is heard and acted upon. Keep your eyes peeled for a survey!


I am very excited to be in this new role and I can’t wait to meet you all through the Developer Community as well as at events as they arise. In the meantime, say hello in the comments or leave me a comment with your best dad joke. I’ll get you started:


Remember, 6 out of 7 dwarfs aren’t happy.
Matt Marum

Sugar 9 has arrived!

Posted by Matt Marum Employee Apr 9, 2019

Hey Sugar devs!


Spring is in the air (for the northern hemisphere)! This can mean only two things: allergy season has started and a new Sugar On-Site release is now available.


Let me introduce to you Sugar 9.0!


See below for all the information Sugar Developers need to know. Sugar end users can be directed over to one of the official Sugar release announcements: the Sugar Spring '19 announcement is for cloud customers and the Sugar 9.0 announcement is for on-premise customers.


In our recent developer webinar we gave an overview of the important changes coming in the Sugar 9.0 On-Site and Sugar Spring ‘19 cloud releases:



The slides from that webinar are available here.


Did you miss the webinar? Want to make sure you’re the first to know about important Sugar product changes? Make sure you are signed up for Sugar Developer News!


Here's a quick overview of what can be expected if upgrading from Winter ‘19

  • Group Outbound Email Support
  • SugarBPM™ improvements
  • Performance and scalability improvements


In addition to the above, here are some of the many additional updates you’ll see if upgrading from Sugar 8.0.

  • Reporting improvements including report scheduling
  • Data Privacy improvements including double opt-in
  • New Quotes configuration panel
  • Emoji support on MySQL (utf8mb4 conversion)
  • Updates to JS libraries including upgrading to jQuery 3
  • Added PHP 7.3 support
  • Updated Microsoft stack support for those hosting on Windows
  • More performance and scalability improvements


Check out the below resources for the rest of the details.

Impatience is a virtue

Larry Wall (the inventor of Perl) is credited with identifying the three great virtues of a programmer: "laziness, impatience, and hubris."


These virtues are usually shared with a wink. For example, a programmer's "laziness" will drive them to get as much work done as possible with the least amount of effort. They say that we'll write automation scripts (in Perl probably) or follow the DRY principle to remove all redundant and unnecessary effort.


I find the "impatience" and "hubris" virtues more interesting.


The virtue of "impatience" is meant to make us "write programs that don't just react to your needs, but actually anticipate them." It also means that we demand a lot from our software. We want it to be as fast, efficient, and proactive as possible. It can be just as satisfying to double the speed of a program as it was to create "v1.0" in the first place.



Impatience is a virtue that I think we share with our Sugar users. We all want Sugar to be responsive and, at best, to be able to provide an insight that anticipates every Sugar user's need. That's why we have a dedicated team of Performance Engineers that work cross-functionally with Product, Operations, and Support teams with the goal to make Sugar fast. REAL FAST.


The last virtue is "hubris" which means that programmers should take great pride in the code they write and the work they do. So let me exercise a little hubris by bragging about what the Performance team has accomplished over the last year.


Performance Testing Apparatus

We've leveraged our experience of running the Sugar cloud to put together an exhaustive  REST API performance test suite of over 15,000 API requests using JMeter. These requests exercise commonly used Sugar functions such as loading List Views, viewing and updating Record Views, performing mass updates, and much more. We combine that by using Tidbit to load the Sugar database with 60GB of data. This data set includes a half million Accounts, two million Contacts, and millions more interaction records.


The combination of JMeter test suite and Tidbit data set serves as the basis for testing and comparing different Sugar versions and build to build. The results below were gathered by running this same test suite against multiple Sugar versions - 8.0.1, 8.0.2, 8.3.0, and a pre-release build of Sugar 9.0.0.


Remember: If you are a Sugar Customer or Partner and you want to have closer look at our JMeter performance test tools, please email Tidbit is an open source project available on our Github organization.


3x to 7x faster Filter API performance since July 2018

The Filter API is one of the most commonly used Sugar REST APIs. It is used to load List Views, Dashlets, Subpanels, and is commonly used by integrations that need to synchronize data between Sugar and an external system.


This API can introduce some performance challenges because it allows access to many records at once using arbitrary filter criteria and sort order. The performance of this API can vary widely depending on the data set, the database schema, and the options being used. So this API has been a particular area of focus for our performance engineers that having been identifying bottlenecks and eliminating them one by one.


As a result, Filter API performance in Sugar 9 has improved by a factor of 3x to 7x as compared to Sugar 8.0.1 which was released less than a year ago in July 2018.



Average API response time cut by more than half since July 2018

The average Sugar 9.0 response time across the 15,000 requests in our test suite is a fraction of what it was in 8.0.1. It is 40% faster than 8.0.2 and 30% faster than even our Winter '19 release. This means that no matter how you are using or integrating with Sugar, you will see significant responsiveness gains by upgrading to Sugar 9.0 (on-premise) or Spring '19 (cloud) when they come out.


ReleaseAverage Response Time
9.0.0 (pre-release)596ms


Increased throughput by 70% on same hardware

If you are using Sugar on-premise, there is a substantial increase in request throughput which can translate to lower hosting costs since more users can be hosted on less hardware. Our testing shows that Sugar 9.0 should process 70% more requests in the same amount of time as the latest Sugar 8.0.2 on-premise release using the same hardware. This should help you stretch hosting dollars further.



Our work is never done

This is a really exciting time to be part of the SugarCRM ecosystem. We are adding many new products and capabilities to the SugarCRM portfolio and our Performance team is here to make sure that all these products meet and exceed our customer's performance expectations.

Hello Sugar Developers!


Are you excited about Sugar 9.0.0?


We want to make sure your customizations and integrations are ready for the Sugar 9.0 (on-premise) and Spring '19 (cloud) releases, so we’re hosting two webinars just for you!


What we will be covering


We’ll discuss the big changes that are likely to impact you including the following:

  • Review of changes in Sugar 8.1Sugar 8.2, and Sugar 8.3
  • Updated Sugar on-premise supported platforms (PHP 7.3, SQL Server 2017)
  • Introducing new REST API version 11.5 11.4 endpoints
  • API performance and scalability enhancements


Webinar Information


We are holding two sessions to accommodate various geographical locations. Please choose ONE of the following times below.


Monday, March 25th 4:30 - 5:30 PM PT OR Tuesday, March 26th 7:00 - 8:00 AM PT (Choose one)


Register Now


As always, we will be posting the webinar recordings to the Sugar Community for those who are unable to attend the live sessions.