Setting the writeback mode
|
Description |
Personal workspace mode Capability mode |
|---|---|
| Changes are made directly to the base. | Off |
| Changes are held in a temporary area and are manually written to the base using the Commit button or option. Cell coloring changes when data is changed but not yet committed. You can process using the Job Queue. | On |
The Sandbox Capability determines if you can name sandboxes or if you have one default sandbox:
|
Description |
Sandbox Capability mode |
|---|---|
| You can name the sandbox and manage multiple sandboxes. | On |
| Only one default sandbox is available. | Off |
The combination of these settings determines how your data changes are stored and processed.
For example, your usergroup may offer direct writeback with named sandboxes. This is the default work design used by TM1®. It means you do not have a personal workspace (instead you have direct writeback to the server), but you also have the option of naming a set of changes and manually submitting them. With this setting, when you first open a view, you are in the base and any changes you make are written directly to the base. But, if you decide to save your changes in a named sandbox, you can use the Commit button when you are ready to manually send those changes to update the base.
Consider the case where you usually want to send the data directly to the server. Then you have a set of changes that you want to gather in a group before you update the server. You can use the Create Sandbox options to save the current data changes in a private sandbox called Best Case. When you are in the Best Case sandbox, you need to use Commit to send the changes to the base and make the changes available to others. After Best Case is committed, those changes merge with the base so others can see the changes and you are now in the newly updated base. If you are working in a sandbox, it is important to remember that you must manually Commit the sandbox for others to see your changes. Be sure you are ready to make those changes public and that those changes should be merged into the base.
If you move back to the base, you are back to using direct writeback. This setting offers a great deal of flexibility. Users with this setting need to remember when they are updating the base and when the Commit button is needed to make changes available to others.
Or, your administrator may decide that you would like the flexibility to work in a personal workspace writeback mode, but you do not want the complexity of creating named sandboxes. In this case, your Administrator can grant you the personal workspace writeback mode but deny the Sandbox capability.