Workspace, Projects, & Migrations

workspace structure a workspace corresponds to your netsuite consultancy all of your trusted employees can be members of the workspace, and have to be invited to that workspace by a workspace admin a workspace can have multiple projects , which correspond to one or more migrations grouped together for a single client typically, a project will only have one production netsuite account (and optionally one or more sandbox netsuite account) a project also handles the authenticaion links to your sources and destinations so if you have admin credentials to a quickbooks online account, or token/key credentials to a netsuite account, you would save the data links at the project level a project can have one or more migrations , which usually has just one source and one production netsuite subsidiary destination (and, optionally, one or more sandbox netsuite subsidiary destinations for testing the migration) at the migration level, you would have subsidiary links , which specifies the subsidiary of a source or destination that is connected via an authentication link also at the migration level, you will see all of your migration reports (which are also visible at the project level) an initial data validation report is generated upon every import from a data source, and lists potential data validation issues with that data, based on standard netsuite data rules further, every mass push into netsuite will generate a report of any errors, such as a record failing custom netsuite validation rules hypothetical example you run suitemagic , a netsuite consulting company with 5 employees you would have a single workspace called either "suitemagic" or "suitemagic workspace" you would be an admin of that workspace, and would invite your 4 staff to be members of that workspace, some of which might also be admins you are hired by "bob's pe rollups" to consolidate 3 hvac companies into one netsuite account, as three subsidiaries you would create a project called "bob's pe 3 hvac rollup" or "hvac rollup for bob's pe" the credentials for the data sources and data destinations are stored at the project level , as authenticaion links so at the project level, you would see three authenticaion links for data sources, one for each of the hvac companies and you would see at minimum one authenticaion link for the destination, the netsuite account however, most consultants will have two netsuite accounts as the destination; one (or more) sandbox(es) acocunt for test migrations, and the production netsuite account so in this example, you might have a total of five authenticaion links at the proejct level (three sources, one netsuite sandbox account, and one netsuite production account) within that project you would also have three migrations , one for each of the three hvac companies let's imagine each was in a different nyc borough you would have three migrations, and they might be named "brooklyn subsidiary" "staten island subsidiary" "queens subsidiary" the naming is entirely up to you, and is whatever makes the most sense for your project you might also add the data source to the name, so it might be "brooklyn hvac quickbooks online" your credentials to connect to the data sources and data destination(s) are stored at the project level in authenticaion links however, at the migration level, you would have subsidiary links which specify additional details such as the subsidiary you would have this subsidiary link even with single subsidiary accounting systems like quickbooks online further, you can change the destination in a given migration you might run the brooklyn hvac company through multiple test migrations to the netsuite sandbox, and then change to the netsuite production account for the final migration before you make the final migration you would create and activate a new subsidiary link, which pointed to a subsidiary of the production netsuite destination (the credentials of which are already at the project leve, in the authentication link) so at this moment you would have two destionations, the inactive one pointing to the netsuite sandbox, and the active one pointing to the production netsuite account while you could in theory change the data source, this is rare you are better off creating a new migration instead of changing the data source you would likely also have multiple reports in each migration for example, every time you connect to a new data source (represented as a subsidiary link), suitemigration would scan the data for likely validation errors for example, quickbooks online allows multiple email addresses in the single email field, but netsuite does not we can identify errors like this even before you attempt to push data to a netsuite subsidiary you will also see a report for each mass migration of data to a destination, which will list all errors and exceptions generated by netsuite visual example