Publishing Templates and Version Control

• Set Access Control
  • Access controls are used to limit the visibility of a project or document
• Examples of Access Control
  • Private to Team Members: Any team members on the Teams tab, regardless of which Project Group they belong to, can view the object. This is the most commonly used Access Control.
  • Private to Internal Users: Internal users (given as a System Permission) can view the object.
  • Owner Only: Only the Project Owner can view the object. This includes not only the direct owner who initially created the project, but also all users in the Project Owner project group.

When managing your templates, a decision that will need to be made is whether or not to include an access control. Access Controls are used to specify which team members have the ability to view a particular project or document. The system does not support the creation of custom access controls so no additional access controls can be created.

If you set an access control on the entire project, all documents in the project are subjected to that access control. If you set an access control for a document, all tasks for the document are also protected by that access control so visibility to the details of those tasks will be hidden based on the access control assigned to the document the task is associated with.

If no access control is set on a project or document, that document is visible to any user in the system as everything in SAP Ariba is visible until an Access Control prevents it.

• Template must be published before it is available for creating workspaces
• From the Overview tab → Properties → click Actions → Publish
• Status changes from Draft to Active

Now that you have created the template, added documents, tasks, team members, conditions and addressed the advanced options, you can now publish your template and make it available for use.

To make a template available to users for workspace creation you must publish the template. From the Overview tab click Actions → Publish. The system will show you a yellow confirmation window indicating that the template has been published successfully and is available for new projects if there are no errors. If you receive errors, correct them and try to publish again.

Once any errors are corrected and the template is published, it moves into the "Active" state. At this point, the template can be viewed, but there will be no options to add or edit anything to that template, even by the owner. It is possible to edit a published template and will be covered later in this course.

Publishing a template also makes it available to end users when creating a contract workspace. Availability of the published template could be restricted by any associated conditions. By default, all users with system permissions to create workspaces can use any template when the conditions are met and that template is in the Active state.

• Editing a template requires it to be in Draft status.
• Therefore, for any existing templates in Active status, you must create a new version if you want to edit.
  • Creating a new version will change it back to a draft status which will allow you to edit.
• While editing, the prior Active version can still be used to create contract workspaces.

Once your template has been published, it goes into the Active status. Once it’s in the Active status, the template becomes locked down in that particular version so no edits or changes can be made. If you want to modify the template, you first have to create a new version of that template. Creating a new version moves the status of the template from Active to Draft and allows that version to be edited. Click on Actions → New Version to move the status of the template from Active to Draft.

The new version of the template will initially be in the Draft state. While you are working on the new version of the template, the prior published version is still available for users to use and create contract workspaces from. Once you have completed your changes you can publish the new version. This action replaces the old version with the newly activated version. Only the active version template can be used to create contract workspaces.

Now that the template is in the draft status, you can start making modifications to that version. When you finish with your changes and publish the template again, it will be the next version. So if you edited version 1 of the template, the status would become version 1 (editing) when you create the new version to indicate that you are currently editing version 1 of the template. After you’ve completed making your modifications and publish the template, the status will go back to Active and will be version 2. Now, when users create workspaces, the system will use the active version 2 of the template.

• Tracks evolution of a template throughout its lifecycle
• Revert Draft option
• Exportable version history in workspace

Templates that have been used cannot be Deleted, only Inactivated. However, a template can be deleted if all projects created from it have been deleted.

A template goes through a "life cycle" of three possible states: Draft, Active and Inactive. When you first create a template, it is in the "Draft" state and the version is ‘Original’. While in draft, the template can be modified by team members but it is not available to end users when creating workspaces. Modifications made to a template in the "Draft" state will not change the version number.

Once the original version is published, the state moves from Draft to Active and the version number changes to version 1. Now, when users create a project, the system will use version 1 of the template to create the project. When a modification is needed, the template owner can click Actions → New Version to change the status from Active back to Draft but this time, the version is v1 (editing). This is to show that you are currently editing version one of the template. Once you’ve finished with your edits to version 1 of the template, publishing will move the status to Active and version 2.

This helps to track the overall evolution of a project template. Users who have visibility to the template will have access to previous versions of the template which can help to show how the process has changed over time. It is also helpful to see the different versions to know which version of the template a particular project used and how that template was built at that time.

Sometimes, you might create a new version of the template and then not make any changes or you realize what you’ve modified was incorrect. You can revert back to the most recently published version of the workspace to discard any changes you’ve made to your template. To do this, from the same Actions menu where you click to create a new version, click Actions → Revert. The system will then provide a confirmation window to ensure you want to revert back to the most recent published version. If you revert, it will not create a new version of the template so in our earlier example, v1 (editing) would go back to v1 after using the revert option, rather than becoming version 2.

• You can only delete templates that haven’t been used to create a workspace or if all of the projects created from that template have been deleted.
• If the template has already been used to create workspaces, you can inactivate the template, which renders it unavailable for the creation of a workspaces.
• Inactive templates can be activated again, if needed.

Deleting a template is rarely necessary and the best practice is to inactivate the template rather than delete it. If a template has never been used to create a workspace, the template owner can delete it. Deleted templates cannot be retrieved, so be sure you want to delete them before you take this action. Templates are usually only deleted when they were created by mistake or the wrong type of template was selected during the creation process. Otherwise, you may want to leave old templates in the site for auditing purposes and just mark it as inactive so it can’t be used in the creation of workspaces.

To help organize templates, you can create a folder for Inactive templates and place any templates with an inactive status into that folder. This way, you will not have to sort through a list of active and inactive templates when looking to modify a template.

• Method of moving templates from one realm to another (e.g. test to production).
• Templates may be exported in any status.
• You do not have to be the owner of the template, but you must be able to view the template project to export it.
• When exporting, the system will create a zip file containing all template information, including documents.

You can also export templates, which may be useful if you want to move templates to another realm, such as a development realm to a production realm. When exporting a template, save the resulting .zip file. The system will automatically title the name of the file with the ID of the workspace template. It is recommended that you rename this file to the name of the template so if you need to use it later, you’ll know which file it is.

You can export templates in any status – draft, active, inactive. You can even export previous versions from the version history tab. This can be especially helpful if you would like to revert back to a prior version of a template. For example, an administrator may accidentally publish a template without wanting to or without it being ready for use. Since a published template can’t be reverted, you can export the desired version and import it back into the system. This will overwrite the published version. This would be one of the few reasons you would export and import within the same site.

• Method of moving templates from one realm to another (e.g. test to production)
• When importing templates from one realm to another, both instances must have:
  • Matching master data
  • When template IDs match, the imported template replaces the existing template.

Once you’ve exported a template, you can import it back into the system. Usually, templates are imported into your production realm after being created and tested within the test realm.

When importing a template, if master data does not exist in the destination site, random master data may be substituted in the imported template for any missing references. For example, users that do not exist in the imported realm will be replaced with other random users. You will have the option to replace with random data or to abort the upload of the template.

If you choose to replace with random master data, the system will select any user regardless of permission and assign them within the project. We do not recommend using this option when moving a template from test to production as it may add users to the team in production that shouldn’t be on the team of that project, whether it be a CEO or a user who just shouldn’t have access.