https://netsuiteprofessionals.com logo
Join Slack
Powered by
I'm new to doing 3rd party software integrations i...
# suitescript
d
I'm new to doing 3rd party software integrations into NetSuite using TBA. Are there any best practices on what kind of entity record or user I should use to generate a token? If I am going to have more integrations in the future should I try to keep all of those tokens under the same user/entity?
b
you dont really have a choice on the type of entity record, your only choice is an employee
using the same employee is very common, especially if you are able to distinguish which record was created by which integration without relying on the created by field
it gets more complicated when integrations start doing updates
d
Right. Does that mean you have to pick an active user or can you create an employee just for the sake of the integration? I have made a psudo-employee just for the sake of the integration, but I find that I have to make sure I remember to update their password before it expires... Or does that user not have to have tradition 'Access'?
b
a single employee for all integration only works if you can tell which integration performed an operation on a record
m
@David Hayden access tokens don't expire when passwords expire fyi
in general I see a few common approaches to create the tokens: 1. Create a brand new user for each integration with only the permissions necessary for that integration to function 2. Create a single user for all integrations. Create one role for each integration (with the minimum permissions required) and assign all of those roles to this new user. Note that when creating tokens, you have to choose a role and a user to bind the token to 3. Don't create any new users. Only create new roles (like in step 2) and assign the roles to an existing NetSuite admin or to the user who "owns" each integration. I would personally go with option 2
d
So option 2, does that newly created user consume a user license?
m
Yup it would. The advantage of that option is you don't have to deal with the headache of a user leaving your company causing an integration to break
but it would just be one additional license (as opposed to option 1, which would be 
n
licenses where 
n
is the number of integrations you have)
d
If that user's password expires the token doesn't expire I am with you there, but does the token still allow access? Does that mean I really would only have to worry with the password if I needed to login as that user for token management or something like that?
m
correct, you would not have to worry about the password. If these are all web services integrations, you could even set up the user as "Web Services Only", meaning the user would not even have UI access
Does that mean I really would only have to worry with the password if I needed to login as that user for token management or something like that?
You wouldn't even need to log in in to deal with token management as this user. You (assuming you are an admin) could assign a token to this other user yourself
d
Ah, I see. I didn't know an you could assign a token as an Admin. Thank you @battk and @Marc Reicher. I hadn't thought along the lines of tracking integrations by user let alone by unique role as well. I'm extra glad to hear that I won't have to worry about logging in during my off time if I neglected to update the password for an integration user for the sake of the token access. I really appreciate the info! Oh and for curiosity's sake the 3rd party software I am integrating is Zoho CRM.
t
Just to throw another spanner in the works, if you are looking to provide your work to multiple NetSuite customers, you should be able to share the integration record via the SuiteBundler to allow for the same server side keys for signing the tokens. But if you are just looking at this from an internal point of view, you can probably not worry about this. You will still need employees to authenticate to generate the tokens, but this can reduce end user setup in some instances
d
@trauty I didn't even consider that it was possible to bundle the integration record. While this is just for one account it might make migrating it from our sandbox instance into production a little easier. For future projects that is really good to know too.
b
probably want to make that integration record in production
will be important when you lose the key
d
@battk Ooooh right, because if it was created in a sandbox it would be gone after a refresh and I would have to do that setup work at that point. That seems like a super bad practice if it was an integration I planned on rolling out to other accounts as well. Assuming I caught your meaning?
b
tends not to matter for single account integrations, where the cost of creating a new integration record is low
you can much more lax for integrations to a single account
d
That is very good to know. Thank you for bringing it up. I wouldn't have known I was being lax about it in the first place.
5 Views
Open in Slack
PreviousNext
Powered by