Django + Salesforce
Blanchard, Bill
Bill will describe how Salesforce.com can be used as a Django database backend. To illustrate, Bill will show how to create a basic app that performs CRUD operations against Salesforce, and he'll review some of the "gotchas" that come with using Salesforce and the django-salesforce library.
 Alright, well I guess we'll get started if you guys have any questions given the nature of the small audience. You're welcome to stop me. So this presentation is on a library called Django Salesforce. It's a library meant to integrate the Salesforce API with the Django ORM so you're able to actually perform Django style queries against Salesforce using the same syntax. So first I'd like to give a nod to the author and maintainer of the Django Salesforce library. It's a small library. These guys do a lot of work, regular updates, so I just wanted to make sure that they were properly acknowledged given I'm presenting on their library. So the main reason to use this library as opposed to any of the other Salesforce integrations that are out there is it's smooth integration with Django. If you're very familiar with Django's way of managing objects then this should be second nature to you. It also minimizes the amount of additional code that you'll have to write if you just need a minor integration. If you're familiar with Salesforce, are you guys familiar with Salesforce? So you're probably aware that the Salesforce SOQL is not exactly SQL much like their Apex language isn't exactly Java. There's always these little catch-ums that you got to be careful of. So the library automatically does the heavy lifting for you without having to necessarily work and worrying about formulating the query appropriately. I actually wrote a patch for Django Salesforce about a year ago where they were implementing the range query filter and it was passing through the normal Django SQL conversion but SOQL doesn't recognize the between operator. So I had to rename it to use less than equal and greater than equal instead of just between. So I'm going to get into some of the downsides of the library so I talk about the usefulness of syncing the data as opposed to just using it for a live poll. If you have a small application, it's okay to get away with doing a live poll but I'll talk a little bit more about why you'd probably want to avoid that above anything but the most trivial projects. I'm going to go ahead and cut into a code example. So I have a small Django application and I'll tweet out the GitHub repo for the example if you're interested in looking at it more. So I have just a basic application with a Leads app and the purpose of this app is to talk to the Leads section of Salesforce. So if I look at my models and I'll zoom out a little bit if it's going to let me. So if you're familiar with Django, you can see that the method for creating objects is the same. However, there's no actual database behind this. The library is just passing this straight through and converting it into a Salesforce query. So if I'm interested in the last name of the lead that I'm looking up, I just define it as a character field with a max length. Now on my slides, I indicate that if you, you can write your own model names or model attributes depending on how you'd like it to implement it but you can just use the default Salesforce Django Salesforce method. If you use the inspect database command, it will dump out every field and every object in Salesforce and then you can just copy paste and pick and choose which ones you like and it will even include the custom fields that you create for your own individual deployment. The important thing is that if you do not use the generated attribute name from Django Salesforce that you define the DB column parameter when you're defining the attribute. So there's some disadvantages to doing it this way. So it's slow and I have a slide that it will show you. I had some new, I've ran some New Relic performance tests. The reason for this is if you're doing anything, if you're querying for an object with anything that has more than a handful of attributes, it's one large query and it's going to hit Salesforce, take time for Salesforce to process, take time for it to return, take time for Django to process and then return it to the end user. So I primarily advocate for using this asynchronously. So maybe a few times a day you'll go out to Salesforce, you'll query the relevant data and bring it into a local database. Again the Salesforce object query language is not straight SQL. It's important to be aware of some of the minor trip ups. Django Salesforce abstracts a lot of this out for you, but if you're going to drop down to raw or extra, then you're probably going to be in trouble. So I wouldn't necessarily recommend you, just because you can doesn't mean you should. There's also some features for the select command that are not supported. Wildcards for obvious reasons because you can get quite a large object in return. Expression expressions, etc., etc. In terms of using this library, if you go through the documentation in terms of how to actually set it up, it requests that you use a Django, I'm sorry, a Salesforce account where you create the user in Salesforce, you specify the appropriate permissions and then you utilize that account. There's some murkiness as it relates to, well if I expose this application to everybody in the world and they're actually doing live Salesforce updates from it, am I evading the Salesforce license? So there's some thought that needs to be put into that. In addition, I have one client that I use this for and they refuse to turn off 90-day mandatory password reset. So every 90 days I have to go into this application and update the password. So Django Salesforce also has an OAuth 2 authentication scheme working with the newer Salesforce OAuth 2 authentication scheme but it's experimental so I wouldn't necessarily advise using it in production. And finally for those of you who've used Salesforce for quite a while, the default API query limit is 15,000 in 24 hours. Ask me how I know. It's easy to fall into the trap if you are experimenting or doing something on production and you run into a large object set to hit that limit relatively quickly. So I really recommend like with everything else that you set up a sandbox environment for Salesforce, test out everything as best you can, import some live data into it that way. And if you're doing a lead.objects.all query, you don't wind up with 15,000 objects. So speaking to the speed, this is some new relic screenshot that I took for a small application that I wrote that all it was doing was displaying call activity information. And you can see that the main time suck was the request out to Salesforce. And to return, I believe this was roughly 10 or 20 objects. It was almost a full second just to get that back into the Django application. So again, I recommend storing the data and querying it asynchronously in anything but the smallest of use cases. So I will actually show you I have in the example application that I wrote how easy it is to just quickly get something up and running and append it to your application. So I attended a tie was two talks ago on a gentleman who had done a lot of Salesforce integration with his clone application. This might be useful if you want to give a small section to your power users to be able to create data in Salesforce, but without having had to have the user go through the training and the headache of learning the whole Salesforce environment. So all this is is a basic crud application create read update delete. This is my list view and you can see really quickly how easy it is just a standard form presentation. And it stores it right in Salesforce. I don't have Salesforce up on this computer right now. If you were to go into Salesforce, you'd see under recent activity brand new lead created. Where if you do some Salesforce side programming, you could use that as well to kick off some automation. The Django Salesforce library doesn't provide much in the way of automation. So you can either use another library that I'll talk about briefly, or you can write the code in Salesforce itself using something like Apex. If we go back to the list view and see that appears as a direct query from Salesforce, I can either edit this or I can just delete it right from here. Obviously be careful with permissions. If I am not careful with my Django application, now I've given somebody the ability to delete materials out of Salesforce without necessarily the appropriate security controls. You can apply security logic to the account that Django Salesforce uses in order to restrict them from accidentally deleting something that they're not supposed to be able to. So for example, if you want them to be able to manage leads but not contacts, you can set up the permissions to be that granular on the Salesforce side. The important thing to remember when also using Django Salesforce is to minimize the number of attributes that you specify on the object to be the minimum that you actually need. In a lot of us, we will grab a handful of things, first name, last name, email, company name, mobile phone, other phone, blah, blah, blah, blah, blah, all the way down the line. If you're not actually using, editing, or displaying mobile phone elsewhere in the application, remove it from your models because then it will always become part of the query out to Salesforce if you do a general filter statement. So it's important to minimize the amount of attributes that you have just to what you need. If you don't pound on this, you're going to be okay. If you do large queries in rapid succession, it's going to be slow. So again, asynchronous data. Now there's some other ways that you can integrate Salesforce with Django and I'm pretty sure both of these will work with Plone as well. There's the old fashioned way, just write it in the request library and query the Salesforce API directly. You can become familiar with their documentation. If you're not a full time Salesforce developer, I probably wouldn't advise it unless you really need that kind of specific access. The beatbox library is pretty good. Salesforce provides two different APIs. The REST API, which is what a lot of us are kind of moving towards, and the SOAP API, which is more for historical stuff. But what's important is that the SOAP API provides a way to do automation. So for example, converting a lead to an account. I don't believe you can, I still believe you cannot do that through the REST API. So if you want that kind of automation, I'd recommend using beatbox. There's also the simple Salesforce library, which provides functionality similar to Django Salesforce, but it doesn't use the Django RRM. It's a specific method of querying the database that abstracts, I'm sorry, that queries Salesforce while abstracting away a lot of the particulars related to the URIs. Any questions on anything that I covered? One of the things that I think about a lot when building things that integrate with Salesforce is the limitation of how many API plus you can use per day in Salesforce. So that again comes back to doing asynchronous behavior. So if you do need to expose this data to an unknown population, an N population where you don't know how high it's going to be, I would recommend policing the data using maybe like Celery, querying Salesforce, bringing it down into a local database and then serving the data from there. You can, based on the number of queries that you'll need to perform, you can tune the frequency of the asynchronous task based on your needs. Any other questions? Okay, well, I was asked to put up the feedback for us, the 6-feet-up app. I appreciate if you give me any kind of feedback on my presentation. And if you're interested in reaching me, my company is Plum Development. We're based out of Portsmouth, New Hampshire, and we are a digital design company specializing in custom web, mobile, and software applications for companies working, companies in the Northeast. And I'm available on GitHub or Twitter at Bill is Plum. Please reach out. Thank you very much. Thank you. Thank you. Awesome. Thank you. Thank you. Awesome. Awesome. Awesome.
 Alright, well I guess we'll get started if you guys have any questions given the nature  of the small audience.  You're welcome to stop me.  So this presentation is on a library called Django Salesforce.  It's a library meant to integrate the Salesforce API with the Django ORM so you're able to  actually perform Django style queries against Salesforce using the same syntax.  So first I'd like to give a nod to the author and maintainer of the Django Salesforce library.  It's a small library.  These guys do a lot of work, regular updates, so I just wanted to make sure that they were  properly acknowledged given I'm presenting on their library.  So the main reason to use this library as opposed to any of the other Salesforce integrations  that are out there is it's smooth integration with Django.  If you're very familiar with Django's way of managing objects then this should be second  nature to you.  It also minimizes the amount of additional code that you'll have to write if you just  need a minor integration.  If you're familiar with Salesforce, are you guys familiar with Salesforce?  So you're probably aware that the Salesforce SOQL is not exactly SQL much like their Apex  language isn't exactly Java.  There's always these little catch-ums that you got to be careful of.  So the library automatically does the heavy lifting for you without having to necessarily  work and worrying about formulating the query appropriately.  I actually wrote a patch for Django Salesforce about a year ago where they were implementing  the range query filter and it was passing through the normal Django SQL conversion but  SOQL doesn't recognize the between operator.  So I had to rename it to use less than equal and greater than equal instead of just between.  So I'm going to get into some of the downsides of the library so I talk about the usefulness  of syncing the data as opposed to just using it for a live poll.  If you have a small application, it's okay to get away with doing a live poll but I'll  talk a little bit more about why you'd probably want to avoid that above anything but the  most trivial projects.  I'm going to go ahead and cut into a code example.  So I have a small Django application and I'll tweet out the GitHub repo for the example  if you're interested in looking at it more.  So I have just a basic application with a Leads app and the purpose of this app is to  talk to the Leads section of Salesforce.  So if I look at my models and I'll zoom out a little bit if it's going to let me.  So if you're familiar with Django, you can see that the method for creating objects is  the same.  However, there's no actual database behind this.  The library is just passing this straight through and converting it into a Salesforce query.  So if I'm interested in the last name of the lead that I'm looking up, I just define it  as a character field with a max length.  Now on my slides, I indicate that if you, you can write your own model names or model  attributes depending on how you'd like it to implement it but you can just use the default  Salesforce Django Salesforce method.  If you use the inspect database command, it will dump out every field and every object  in Salesforce and then you can just copy paste and pick and choose which ones you like and  it will even include the custom fields that you create for your own individual deployment.  The important thing is that if you do not use the generated attribute name from Django  Salesforce that you define the DB column parameter when you're defining the attribute.  So there's some disadvantages to doing it this way.  So it's slow and I have a slide that it will show you.  I had some new, I've ran some New Relic performance tests.  The reason for this is if you're doing anything, if you're querying for an object with anything  that has more than a handful of attributes, it's one large query and it's going to hit  Salesforce, take time for Salesforce to process, take time for it to return, take time for  Django to process and then return it to the end user.  So I primarily advocate for using this asynchronously.  So maybe a few times a day you'll go out to Salesforce, you'll query the relevant data  and bring it into a local database.  Again the Salesforce object query language is not straight SQL.  It's important to be aware of some of the minor trip ups.  Django Salesforce abstracts a lot of this out for you, but if you're going to drop down  to raw or extra, then you're probably going to be in trouble.  So I wouldn't necessarily recommend you, just because you can doesn't mean you should.  There's also some features for the select command that are not supported.  Wildcards for obvious reasons because you can get quite a large object in return.  Expression expressions, etc., etc.  In terms of using this library, if you go through the documentation in terms of how  to actually set it up, it requests that you use a Django, I'm sorry, a Salesforce account  where you create the user in Salesforce, you specify the appropriate permissions and then  you utilize that account.  There's some murkiness as it relates to, well if I expose this application to everybody  in the world and they're actually doing live Salesforce updates from it, am I evading the  Salesforce license?  So there's some thought that needs to be put into that.  In addition, I have one client that I use this for and they refuse to turn off 90-day  mandatory password reset.  So every 90 days I have to go into this application and update the password.  So Django Salesforce also has an OAuth 2 authentication scheme working with the newer  Salesforce OAuth 2 authentication scheme but it's experimental so I wouldn't necessarily  advise using it in production.  And finally for those of you who've used Salesforce for quite a while, the default API query limit  is 15,000 in 24 hours.  Ask me how I know.  It's easy to fall into the trap if you are experimenting or doing something on production  and you run into a large object set to hit that limit relatively quickly.  So I really recommend like with everything else that you set up a sandbox environment  for Salesforce, test out everything as best you can, import some live data into it that  way.  And if you're doing a lead.objects.all query, you don't wind up with 15,000 objects.  So speaking to the speed, this is some new relic screenshot that I took for a small application  that I wrote that all it was doing was displaying call activity information.  And you can see that the main time suck was the request out to Salesforce.  And to return, I believe this was roughly 10 or 20 objects.  It was almost a full second just to get that back into the Django application.  So again, I recommend storing the data and querying it asynchronously in anything but  the smallest of use cases.  So I will actually show you I have in the example application that I wrote how easy  it is to just quickly get something up and running and append it to your application.  So I attended a tie was two talks ago on a gentleman who had done a lot of Salesforce  integration with his clone application.  This might be useful if you want to give a small section to your power users to be able  to create data in Salesforce, but without having had to have the user go through the  training and the headache of learning the whole Salesforce environment.  So all this is is a basic crud application create read update delete.  This is my list view and you can see really quickly how easy it is just a standard form  presentation.  And it stores it right in Salesforce.  I don't have Salesforce up on this computer right now.  If you were to go into Salesforce, you'd see under recent activity brand new lead created.  Where if you do some Salesforce side programming, you could use that as well to kick off some  automation.  The Django Salesforce library doesn't provide much in the way of automation.  So you can either use another library that I'll talk about briefly, or you can write  the code in Salesforce itself using something like Apex.  If we go back to the list view and see that appears as a direct query from Salesforce,  I can either edit this or I can just delete it right from here.  Obviously be careful with permissions.  If I am not careful with my Django application, now I've given somebody the ability to delete  materials out of Salesforce without necessarily the appropriate security controls.  You can apply security logic to the account that Django Salesforce uses in order to restrict  them from accidentally deleting something that they're not supposed to be able to.  So for example, if you want them to be able to manage leads but not contacts, you can  set up the permissions to be that granular on the Salesforce side.  The important thing to remember when also using Django Salesforce is to minimize the  number of attributes that you specify on the object to be the minimum that you actually  need.  In a lot of us, we will grab a handful of things, first name, last name, email, company  name, mobile phone, other phone, blah, blah, blah, blah, blah, all the way down the line.  If you're not actually using, editing, or displaying mobile phone elsewhere in the application,  remove it from your models because then it will always become part of the query out to  Salesforce if you do a general filter statement.  So it's important to minimize the amount of attributes that you have just to what you  need.  If you don't pound on this, you're going to be okay.  If you do large queries in rapid succession, it's going to be slow.  So again, asynchronous data.  Now there's some other ways that you can integrate Salesforce with Django and I'm pretty sure  both of these will work with Plone as well.  There's the old fashioned way, just write it in the request library and query the Salesforce  API directly.  You can become familiar with their documentation.  If you're not a full time Salesforce developer, I probably wouldn't advise it unless you really  need that kind of specific access.  The beatbox library is pretty good.  Salesforce provides two different APIs.  The REST API, which is what a lot of us are kind of moving towards, and the SOAP API, which  is more for historical stuff.  But what's important is that the SOAP API provides a way to do automation.  So for example, converting a lead to an account.  I don't believe you can, I still believe you cannot do that through the REST API.  So if you want that kind of automation, I'd recommend using beatbox.  There's also the simple Salesforce library, which provides functionality similar to Django  Salesforce, but it doesn't use the Django RRM.  It's a specific method of querying the database that abstracts, I'm sorry, that queries Salesforce  while abstracting away a lot of the particulars related to the URIs.  Any questions on anything that I covered?  One of the things that I think about a lot when building things that integrate with Salesforce  is the limitation of how many API plus you can use per day in Salesforce.  So that again comes back to doing asynchronous behavior.  So if you do need to expose this data to an unknown population, an N population where  you don't know how high it's going to be, I would recommend policing the data using  maybe like Celery, querying Salesforce, bringing it down into a local database and then serving  the data from there.  You can, based on the number of queries that you'll need to perform, you can tune the frequency  of the asynchronous task based on your needs.  Any other questions?  Okay, well, I was asked to put up the feedback for us, the 6-feet-up app.  I appreciate if you give me any kind of feedback on my presentation.  And if you're interested in reaching me, my company is Plum Development.  We're based out of Portsmouth, New Hampshire, and we are a digital design company specializing  in custom web, mobile, and software applications for companies working, companies in the Northeast.  And I'm available on GitHub or Twitter at Bill is Plum.  Please reach out.  Thank you very much.  Thank you.  Thank you.  Awesome.  Thank you.  Thank you.  Awesome.  Awesome.  Awesome.
Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_0_155.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_156_3803.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_3804_4427.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_4428_4475.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_4476_5387.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_5388_5459.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_5460_8087.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_8088_11327.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_11328_12395.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_12396_12539.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_12540_12935.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_12936_13007.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_13008_13127.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_13128_15095.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_15096_16019.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_16020_19463.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_19464_21299.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_21300_21563.png Day_2__Django___Salesforce__by_Bill_Blanchard_BVGt9X9GAp0_21564_22281.png
Alright, well I guess we'll get started if you guys have any questions given the nature of the small audience. You're welcome to stop me. So this presentation is on a library called Django Salesforce. It's a library meant to integrate the Salesforce API with the Django ORM so you're able to actually perform Django style queries against Salesforce using the same syntax. So first I'd like to give a nod to the author and maintainer of the Django Salesforce library. It's a small library. These guys do a lot of work, regular updates, so I just wanted to make sure that they were properly acknowledged given I'm presenting on their library. So the main reason to use this library as opposed to any of the other Salesforce integrations that are out there is it's smooth integration with Django. If you're very familiar with Django's way of managing objects then this should be second nature to you. It also minimizes the amount of additional code that you'll have to write if you just need a minor integration. If you're familiar with Salesforce, are you guys familiar with Salesforce? So you're probably aware that the Salesforce SOQL is not exactly SQL much like their Apex language isn't exactly Java. There's always these little catch-ums that you got to be careful of. So the library automatically does the heavy lifting for you without having to necessarily work and worrying about formulating the query appropriately. I actually wrote a patch for Django Salesforce about a year ago where they were implementing the range query filter and it was passing through the normal Django SQL conversion but SOQL doesn't recognize the between operator. So I had to rename it to use less than equal and greater than equal instead of just between. So I'm going to get into some of the downsides of the library so I talk about the usefulness of syncing the data as opposed to just using it for a live poll. If you have a small application, it's okay to get away with doing a live poll but I'll talk a little bit more about why you'd probably want to avoid that above anything but the most trivial projects. I'm going to go ahead and cut into a code example. So I have a small Django application and I'll tweet out the GitHub repo for the example if you're interested in looking at it more. So I have just a basic application with a Leads app and the purpose of this app is to talk to the Leads section of Salesforce. So if I look at my models and I'll zoom out a little bit if it's going to let me. So if you're familiar with Django, you can see that the method for creating objects is the same. However, there's no actual database behind this. The library is just passing this straight through and converting it into a Salesforce query. So if I'm interested in the last name of the lead that I'm looking up, I just define it as a character field with a max length. Now on my slides, I indicate that if you, you can write your own model names or model attributes depending on how you'd like it to implement it but you can just use the default Salesforce Django Salesforce method. If you use the inspect database command, it will dump out every field and every object in Salesforce and then you can just copy paste and pick and choose which ones you like and it will even include the custom fields that you create for your own individual deployment. The important thing is that if you do not use the generated attribute name from Django Salesforce that you define the DB column parameter when you're defining the attribute. So there's some disadvantages to doing it this way. So it's slow and I have a slide that it will show you. I had some new, I've ran some New Relic performance tests. The reason for this is if you're doing anything, if you're querying for an object with anything that has more than a handful of attributes, it's one large query and it's going to hit Salesforce, take time for Salesforce to process, take time for it to return, take time for Django to process and then return it to the end user. So I primarily advocate for using this asynchronously. So maybe a few times a day you'll go out to Salesforce, you'll query the relevant data and bring it into a local database. Again the Salesforce object query language is not straight SQL. It's important to be aware of some of the minor trip ups. Django Salesforce abstracts a lot of this out for you, but if you're going to drop down to raw or extra, then you're probably going to be in trouble. So I wouldn't necessarily recommend you, just because you can doesn't mean you should. There's also some features for the select command that are not supported. Wildcards for obvious reasons because you can get quite a large object in return. Expression expressions, etc., etc. In terms of using this library, if you go through the documentation in terms of how to actually set it up, it requests that you use a Django, I'm sorry, a Salesforce account where you create the user in Salesforce, you specify the appropriate permissions and then you utilize that account. There's some murkiness as it relates to, well if I expose this application to everybody in the world and they're actually doing live Salesforce updates from it, am I evading the Salesforce license? So there's some thought that needs to be put into that. In addition, I have one client that I use this for and they refuse to turn off 90-day mandatory password reset. So every 90 days I have to go into this application and update the password. So Django Salesforce also has an OAuth 2 authentication scheme working with the newer Salesforce OAuth 2 authentication scheme but it's experimental so I wouldn't necessarily advise using it in production. And finally for those of you who've used Salesforce for quite a while, the default API query limit is 15,000 in 24 hours. Ask me how I know. It's easy to fall into the trap if you are experimenting or doing something on production and you run into a large object set to hit that limit relatively quickly. So I really recommend like with everything else that you set up a sandbox environment for Salesforce, test out everything as best you can, import some live data into it that way. And if you're doing a lead.objects.all query, you don't wind up with 15,000 objects. So speaking to the speed, this is some new relic screenshot that I took for a small application that I wrote that all it was doing was displaying call activity information. And you can see that the main time suck was the request out to Salesforce. And to return, I believe this was roughly 10 or 20 objects. It was almost a full second just to get that back into the Django application. So again, I recommend storing the data and querying it asynchronously in anything but the smallest of use cases. So I will actually show you I have in the example application that I wrote how easy it is to just quickly get something up and running and append it to your application. So I attended a tie was two talks ago on a gentleman who had done a lot of Salesforce integration with his clone application. This might be useful if you want to give a small section to your power users to be able to create data in Salesforce, but without having had to have the user go through the training and the headache of learning the whole Salesforce environment. So all this is is a basic crud application create read update delete. This is my list view and you can see really quickly how easy it is just a standard form presentation. And it stores it right in Salesforce. I don't have Salesforce up on this computer right now. If you were to go into Salesforce, you'd see under recent activity brand new lead created. Where if you do some Salesforce side programming, you could use that as well to kick off some automation. The Django Salesforce library doesn't provide much in the way of automation. So you can either use another library that I'll talk about briefly, or you can write the code in Salesforce itself using something like Apex. If we go back to the list view and see that appears as a direct query from Salesforce, I can either edit this or I can just delete it right from here. Obviously be careful with permissions. If I am not careful with my Django application, now I've given somebody the ability to delete materials out of Salesforce without necessarily the appropriate security controls. You can apply security logic to the account that Django Salesforce uses in order to restrict them from accidentally deleting something that they're not supposed to be able to. So for example, if you want them to be able to manage leads but not contacts, you can set up the permissions to be that granular on the Salesforce side. The important thing to remember when also using Django Salesforce is to minimize the number of attributes that you specify on the object to be the minimum that you actually need. In a lot of us, we will grab a handful of things, first name, last name, email, company name, mobile phone, other phone, blah, blah, blah, blah, blah, all the way down the line. If you're not actually using, editing, or displaying mobile phone elsewhere in the application, remove it from your models because then it will always become part of the query out to Salesforce if you do a general filter statement. So it's important to minimize the amount of attributes that you have just to what you need. If you don't pound on this, you're going to be okay. If you do large queries in rapid succession, it's going to be slow. So again, asynchronous data. Now there's some other ways that you can integrate Salesforce with Django and I'm pretty sure both of these will work with Plone as well. There's the old fashioned way, just write it in the request library and query the Salesforce API directly. You can become familiar with their documentation. If you're not a full time Salesforce developer, I probably wouldn't advise it unless you really need that kind of specific access. The beatbox library is pretty good. Salesforce provides two different APIs. The REST API, which is what a lot of us are kind of moving towards, and the SOAP API, which is more for historical stuff. But what's important is that the SOAP API provides a way to do automation. So for example, converting a lead to an account. I don't believe you can, I still believe you cannot do that through the REST API. So if you want that kind of automation, I'd recommend using beatbox. There's also the simple Salesforce library, which provides functionality similar to Django Salesforce, but it doesn't use the Django RRM. It's a specific method of querying the database that abstracts, I'm sorry, that queries Salesforce while abstracting away a lot of the particulars related to the URIs. Any questions on anything that I covered? One of the things that I think about a lot when building things that integrate with Salesforce is the limitation of how many API plus you can use per day in Salesforce. So that again comes back to doing asynchronous behavior. So if you do need to expose this data to an unknown population, an N population where you don't know how high it's going to be, I would recommend policing the data using maybe like Celery, querying Salesforce, bringing it down into a local database and then serving the data from there. You can, based on the number of queries that you'll need to perform, you can tune the frequency of the asynchronous task based on your needs. Any other questions? Okay, well, I was asked to put up the feedback for us, the 6-feet-up app. I appreciate if you give me any kind of feedback on my presentation. And if you're interested in reaching me, my company is Plum Development. We're based out of Portsmouth, New Hampshire, and we are a digital design company specializing in custom web, mobile, and software applications for companies working, companies in the Northeast. And I'm available on GitHub or Twitter at Bill is Plum. Please reach out. Thank you very much. Thank you. Thank you. Awesome. Thank you. Thank you. Awesome. Awesome. Awesome.
get into some of the downsides of the library so with a Leads app and the purpose of this app is Salesforce and then you can just copy paste and and I have a slide that it will show you. I had Salesforce environment. So all this is is a basic when also using Django Salesforce is to minimize