NetClose - Document Management Security & FAQs
Overview
Customers evaluating the Document Management integration - SharePoint or Google Drive - often need a security review before they connect it. This article answers the questions we see most often about how NetClose talks to each provider, what access it holds, how tokens and data are protected, and what NetClose does and doesn't retain. Most answers are identical regardless of which provider you use; where they differ, both are called out.
Integration and authentication
How does NetClose integrate with SharePoint or Google Drive - is it direct, or through an intermediary service?
NetClose connects directly to whichever provider's own API you use - the Microsoft Graph API (a Microsoft Azure service) for SharePoint, or the Google Drive API for Google Drive. In both cases NetSuite calls that API directly; there's no separate third-party intermediary in the path.
What authentication method does NetClose use - OAuth 2.0, Microsoft Entra ID (Azure AD), client certificates, or something else?
Both connections use the OAuth 2.0 authorization code flow. Netgain has an application registered with each provider - an Entra ID (Azure AD) app registration with an application-wide client secret for SharePoint, and the equivalent OAuth client registration with Google for Google Drive. Neither integration uses client certificate authentication.
Permissions and access scope
What permissions does NetClose require? Are they scoped to specific sites/libraries or folders, and does this follow least privilege?
Both providers use the same delegated, scoped-to-user permission model - the application acts on behalf of the user who authenticated it, not under its own standing identity.
- SharePoint: NetClose requests read/write access to Sites as well as Files.
- Google Drive: NetClose requests access to the user's Drive - the same level of access that user has when working in the Google Drive UI directly (not the narrower
drive.filescope, which would limit the app to only files/folders it created or the user explicitly picked).
Neither provider scopes the resulting token down to a specific site, library, or folder. In both cases, the access token is technically capable of anything the authenticating user could do manually in that provider's UI, within that user's own permissions - including admin-level actions if the authenticating user happens to be an admin. NetClose's scripts never issue admin-level requests, but the token they hold could technically be used for one.
Least privilege in practice is enforced by what NetClose's scripts actually do, not by the token's technical reach: NetClose only reads and writes inside the single folder configured at setup - the "Netgain Tools" folder (or the subfolder path you specify) for SharePoint, or the specific Folder ID you enter on the Global Settings record for Google Drive. Customers who want to bound the token's technical exposure should authenticate with a dedicated, non-admin user whose own SharePoint or Google Drive access is already limited to what NetClose needs, rather than an administrator's account.
What access does Netgain Tools actually gain to the site or Drive account?
The same behavior on both: the app gains access to everything the authenticating user can access, because the permission grant is scoped to that user, not to the app. In practice, NetClose's scripts only operate inside the one folder configured on the Global Settings record - the Netgain Tools folder for SharePoint, or the configured Folder ID for Google Drive - even though the underlying token could technically reach further.
Does the authenticating user need SharePoint Super Admin/Site Admin rights, or a Google Workspace admin role?
NetClose doesn't require admin rights to authenticate, for either provider. Whether an admin has to perform or approve the connection is a customer-specific policy choice: some organizations restrict third-party application access to admins only in their own Microsoft or Google account settings, in which case an admin authenticates or approves the connection there. That's a customer-side restriction set in their own tenant, not a requirement NetClose imposes.
Do all NetClose users need SharePoint site access or Google Drive access?
No, for either provider. Any NetClose user can trigger a file sync once the connection is set up. Only the one user who performs the initial authentication needs access to the SharePoint site or Google Drive folder.
Token lifecycle and security
Are access tokens short-lived? Are refresh tokens used? How are tokens protected?
Yes. Access tokens last about an hour for both SharePoint and Google Drive. A scheduled script checks token validity and requests a new access token using the refresh token whenever the current one has expired, so reconciliation sync doesn't require manual re-authentication under normal use - the refresh process works the same way for both providers. Tokens are stored the same way for both: in a Long Text field on the Netgain Tools Setup record in NetSuite (separate fields per provider - for example, the "Google Drive Access Token" field for Google Drive). They aren't stored or transmitted anywhere outside NetSuite. See Encryption below for how that field is protected.
Can tokens be revoked immediately if required?
Yes, for both. Revocation happens on the provider's side, not NetSuite's: an admin (or the authenticating user) can revoke NetClose's access from the customer's Microsoft/Entra ID account for SharePoint, or from the customer's Google/Workspace account for Google Drive, at any time. Once revoked, the stored refresh token stops working on its next use, and a user needs to re-authenticate through the Microsoft or Google Authentication link to restore the connection.
Data storage and retention
Does NetClose store copies of documents, or only metadata?
Metadata only, for both. The only information NetClose stores is what's entered on the Document Management setup page - the SharePoint site URL, folder path, and tokens, or the Google Drive Folder ID and access token - plus the parent folder ID for each reconciliation group or dimension. Document content is never copied into NetSuite; every file is queried from SharePoint or Google Drive through the provider's API on demand, each time it's needed.
What data is retained, what's the default retention period, and is it customer-configurable?
Only the data described above: the setup-page values and the parent folder IDs. That data persists for as long as Document Management is configured - there's no separate retention timer, expiration, or configurable retention period on it, since it simply reflects the current connection state rather than a log or history. This excludes anything NetSuite's N/https module or a browser might cache independently, which NetClose doesn't control.
How long is data retained if the connection is removed? Is there a customer delete option?
The same data described above, and it's under the customer's direct control. An administrator can clear the SharePoint site URL, folder path, and tokens (or the Google Drive Folder ID and token) from the Global Settings record, and clear the stored parent folder IDs on affected reconciliation groups or dimensions, at any time - there's no separate deletion request process, since these are fields on records the customer already owns in their own NetSuite account.
Is any data cached or stored outside NetSuite/NetClose?
No.
Encryption
What encryption mechanisms protect this data in transit and at rest, and who manages the encryption keys?
All SharePoint and Google Drive traffic, and the credentials stored for either, are handled through NetSuite's native N/https module, so encryption in transit and at rest follows NetSuite's own platform handling. NetClose doesn't run a separate encryption layer or manage its own keys for either provider. For the specifics of NetSuite's encryption implementation and key management, that's a NetSuite platform question rather than a NetClose one.
Logging and audit
Are user activities and administrative actions logged?
Only through NetSuite's native mechanisms - NetClose doesn't run a separate audit log for document management, regardless of provider. Script-level activity (syncs, errors) is captured in NetSuite's Script Execution Log, the same place other NetClose jobs log to. When a user action creates or changes a record - for example, a sync that creates reconciliation items - that shows up in the record's NetSuite System Notes.
How long are audit logs retained, and how does that relate to NetSuite's own retention?
That's governed by NetSuite's platform retention for script logs and system notes - NetClose doesn't configure or extend it for either provider. Check with NetSuite, or your NetSuite administrator, for the specific retention in your account.
Can logs be exported to a customer's SIEM?
NetClose doesn't provide a SIEM export feature for either provider. Whether NetSuite's own logs - or your Microsoft/Google tenant's own admin-side logs - can be exported to a SIEM is a platform capability of NetSuite, Microsoft, or Google respectively, outside what NetClose controls.
Network requirements
Are network restrictions supported - IP allowlisting, private endpoints, tenant restrictions? Does the integration require inbound connectivity?
NetClose only needs outbound connectivity from NetSuite to the customer's SharePoint site or Google Drive - no inbound connections into the customer's network are required for either. That traffic runs through NetSuite's N/https module, so IP allowlisting, private endpoints, and tenant restrictions are governed by NetSuite's outbound networking and whatever the customer configures on the Microsoft/Entra ID or Google/Workspace side to accept or restrict application traffic - NetClose doesn't add a separate networking layer.
