RegoXchange
  • The Portlets and NSQL Queries portlet displays portlets built from queries.  The portlet provides the administrator with the ability to search queries developed in the past that may have a certain attribute within it.  This is helpful during upgrades when CA makes data model changes.
  • Portlets on Pages displays portlets located on each page within Clarity. This portlet is useful for administrators to determine which users have customized their pages and if they are not seeing a certain portlet, or if a user has placed a portlet on another page and needs help locating it. It also shows the portlet code, name, page the portlet resides on, tab type, who created the tab, source type, and the object/query.
  • Portlets on Pages displays portlets located on each page within Clarity. This portlet is useful for administrators to determine which users have customized their pages and if they are not seeing a certain portlet, or if a user has placed a portlet on another page and needs help locating it. It also shows the portlet code, name, page the portlet resides on, tab type, who created the tab, source type, and the object/query.
  • Portlets on Pages displays portlets located on each page within Clarity. This portlet is useful for administrators to determine which users have customized their pages and if they are not seeing a certain portlet, or if a user has placed a portlet on another page and needs help locating it. It also shows the portlet code, name, page the portlet resides on, tab type, who created the tab, source type, and the object/query.
  • The Process Instance Errors portlet will show all processes that error. This portlet will assist the administrator with determining which processes are in error and whether to skip, retry, or cancel. It will display the process name, code, start date, and who initiated the process. You may also filter by any of the criteria listed in the grid.
  • The Process Instance Errors portlet will show all processes that error. This portlet will assist the administrator with determining which processes are in error and whether to skip, retry, or cancel. It will display the process name, code, start date, and who initiated the process. You may also filter by any of the criteria listed in the grid.
  • The Process Instance Errors portlet will show all processes that error. This portlet will assist the administrator with determining which processes are in error and whether to skip, retry, or cancel. It will display the process name, code, start date, and who initiated the process. You may also filter by any of the criteria listed in the grid.
  • The Project Attachments portlet displays all attachments located on every project, regardless of security rights. This portlet is useful for not only the PM, but also the PMO to determine if a document has been uploaded for the toll gating process. It will also display the folder type, folder path, folder name, and file name. You have the ability to filter by project name, code, file name or file name.
  • The Project Attachments portlet displays all attachments located on every project, regardless of security rights. This portlet is useful for not only the PM, but also the PMO to determine if a document has been uploaded for the toll gating process. It will also display the folder type, folder path, folder name, and file name. You have the ability to filter by project name, code, file name or file name.
  • The Project Attachments portlet displays all attachments located on every project, regardless of security rights. This portlet is useful for not only the PM, but also the PMO to determine if a document has been uploaded for the toll gating process. It will also display the folder type, folder path, folder name, and file name. You have the ability to filter by project name, code, file name or file name.
  • The Projects Marked for Deletion portlet displays information about projects that are currently pending deletion but excludes templates and programs. This portlet provides an easy way to view all projects that are marked for deletion before the background job actually erases them. The portlet provides all necessary information as well as the project manager in case there are questions about why the project was marked for deletion.
  • The Projects Marked for Deletion portlet displays information about projects that are currently pending deletion but excludes templates and programs. This portlet provides an easy way to view all projects that are marked for deletion before the background job actually erases them. The portlet provides all necessary information as well as the project manager in case there are questions about why the project was marked for deletion.
  • The Projects Marked for Deletion portlet displays information about projects that are currently pending deletion but excludes templates and programs. This portlet provides an easy way to view all projects that are marked for deletion before the background job actually erases them. The portlet provides all necessary information as well as the project manager in case there are questions about why the project was marked for deletion.
  • The Projects That Should Be Closed portlet displays all projects that have been created before the specified filter date and has had no new time, tasks, or risks/issues updated after the dates specified in the filter.  This can assist in identifying projects that are completed or cancelled and should be closed. The table below describes the available columns in the portlet.
    Column Label Description
    Project Name Name of the project
    PM Manager of the project
    Created Date Created Date of the project
    Start Start Date of the project
    Finish Finish Date of the project
    Created Date Check Identifies if the project meets the Created Before (Days) filter
    Risks/Issues Check Identifies if the project meets the Risk/Issues – Days Back filter
    Task Check Identifies if the project meets the Task – Days Back filter
    Time Check Identifies if the project meets the Time – Days Back filter
    Project Check Identifies if the project meets the portlet filter Criteria
    id Internal code used by the query
       
  • The Projects That Should Be Closed portlet displays all projects that have been created before the specified filter date and has had no new time, tasks, or risks/issues updated after the dates specified in the filter.  This can assist in identifying projects that are completed or cancelled and should be closed. The table below describes the available columns in the portlet.
    Column Label Description
    Project Name Name of the project
    PM Manager of the project
    Created Date Created Date of the project
    Start Start Date of the project
    Finish Finish Date of the project
    Created Date Check Identifies if the project meets the Created Before (Days) filter
    Risks/Issues Check Identifies if the project meets the Risk/Issues – Days Back filter
    Task Check Identifies if the project meets the Task – Days Back filter
    Time Check Identifies if the project meets the Time – Days Back filter
    Project Check Identifies if the project meets the portlet filter Criteria
    id Internal code used by the query
       
  • The Projects That Should Be Closed portlet displays all projects that have been created before the specified filter date and has had no new time, tasks, or risks/issues updated after the dates specified in the filter.  This can assist in identifying projects that are completed or cancelled and should be closed. The table below describes the available columns in the portlet.
    Column Label Description
    Project Name Name of the project
    PM Manager of the project
    Created Date Created Date of the project
    Start Start Date of the project
    Finish Finish Date of the project
    Created Date Check Identifies if the project meets the Created Before (Days) filter
    Risks/Issues Check Identifies if the project meets the Risk/Issues – Days Back filter
    Task Check Identifies if the project meets the Task – Days Back filter
    Time Check Identifies if the project meets the Time – Days Back filter
    Project Check Identifies if the project meets the portlet filter Criteria
    id Internal code used by the query
       
  • The Resource Rights portlet displays information for all global, OBS, and instance-based rights that are present in the system. This portlet can easily determine who has certain rights and what is causing them to retain a certain license status (creator, studio developer, etc).
  • The Resource Vacation Details portlet allows a resource manager, or administrator, to see a resource’s calendar at a glance, displayed by week or month for a selected time period.  This portlet shows the Resource Name, Resource Manager, Calendar, H (holiday), and V (vacation) hours for the select time frame.
  • The Resource Vacation Details portlet allows a resource manager, or administrator, to see a resource’s calendar at a glance, displayed by week or month for a selected time period.  This portlet shows the Resource Name, Resource Manager, Calendar, H (holiday), and V (vacation) hours for the select time frame.
  • The Resource Vacation Details portlet allows a resource manager, or administrator, to see a resource’s calendar at a glance, displayed by week or month for a selected time period.  This portlet shows the Resource Name, Resource Manager, Calendar, H (holiday), and V (vacation) hours for the select time frame.
  • The Resources in Security Groups portlet shows security group information for resources. (Note: the information displayed is dependent on what the user has security rights to view.) The portlet displays the Group, Group ID, if the Group is active, Resource, User Name and User Status. This portlet also includes the ability to filter on a specific group or resource, by whether the group is active, by user status or OBS.
  • Installation files are not provided with the download.  While the MUX Migration Tool is free, it does require some time by Rego Technical Staff to install.  Approximately 4 hours is required.  If you are current Rego Customer, this time can be applied against a current project if you choose, or against an Ad Hoc SOW/PO you have in place with us. Please reach out to your friendly Rego Account Director to arrange to have the tool installed.  Installation files are not provided with this download.  They will be installed by our staff. If you are currently not a Rego client, we invite you to reach out to us at info@regoconsulting.com and we can arrange to set up an Ad Hoc bucket of hours for this install and any future work we can do for you.
    *Note:  MUX Migrator v2.0 will only work on Clarity versions 16.1.0 and higher.   The Migration Tool for Modern UX Components provides the ability to migrate Blueprints, Views, and Field Level Security between environments.  Previously, the promotion of these components needed to be done manually.  This functionality, to be utilized by an administrator, is available under the Custom Objects Area of Clarity. Source to Target Approach The user would first create an ‘MUX Migrator’ instance and populate the associated details.  Once ready, they will use the “Populate Stage Content” action which will run a workflow in the background to populate a Staging Table with Source Environments content.  (Blueprints, Views, and Field Level Security)
    After a successful populate, they would navigate to the “MUX Configuration” module where they can decide on what content they want to migrate between environments.  They can select one to many components they wish to migrate. Once the “MUX Configuration” sub-object is populated, the user can navigate back to the “Properties” module.  Once a password is populated, the user can use the Actions drop-down to run the “Migrate Content to Environment” workflow.  This will run a process that will migrate the content from the source environment to the target environment. JSON Approach The user would first create an ‘MUX Migrator’ instance and populate the associated details.  They would navigate to the “MUX Configuration” module where they can decide on what content they want to migrate between environments.  They can select one to many components they wish to migrate. Once the “MUX Configuration” sub-object is populated, the user can navigate back to the “Properties” module.  The user can use the Actions drop-down to run the “Export JSON” workflow.  This will run a process that will generate a .txt file located in the “JSON File” attribute.  That file can be downloaded from the Source Environment.  The user can then login to the Target Environment.  The user would first create an ‘MUX Migrator’ instance and populate the associated details.  Once the ‘MUX Migrator’ instance is created, they can upload the JSON File that was downloaded from the Source Environment.  The user can use the Actions drop-down to run the “Import JSON” workflow.  This will run a process that will generate read the file located in the “JSON File” attribute and load the configuration into the Target Environment. View Administration The user would first create an ‘MUX Migrator’ instance and populate the associated details.  They would navigate to the “MUX View Administration” module where they can decide on what views they would like to update the creator of.  They can also reset the “default” view displayed when logged in for a resource(s), Security Group(s), or Resource OBS Node(s). Prerequisites
    • The user will create the migrator instances/run the processes in the Target Environment they wish to migrate content to (E.g., Run this in PROD to migrate the content from a lower environment to PROD)
    • Any attributes that are part of the Blueprints, Views, or Field Level Security must exist in the target environment.
    • The user that is utilizing the content must have the following security rights associated to their account.
      • XOG rights to all the associated objects
      • View/edit security rights to the MUX Migrator Object and MUX Migrator Content Object
      • oView rights to the MUX Migrator Staging Table Object
      • API-Access
      • Process Start or Process AutoStart – All
  • The Update Email Ids workflow sets all users’ email addresses to non-working by appending a “ZZZZ” to the end of the email address. This process is used for when there are refreshes to your Development or Testing environments and do not want emails going to users. When complete, the log will display the total amount of email addresses updated. A second process is included in this workflow that will revert the email addresses to remove the “ZZZZ” added in the first workflow. In some instances, the process may be run in error, or you may want to send emails from a Development or Testing environment; using this second process you will be able to enable all emails again.
  • The Update Email Ids workflow sets all users’ email addresses to non-working by appending a “ZZZZ” to the end of the email address. This process is used for when there are refreshes to your Development or Testing environments and do not want emails going to users. When complete, the log will display the total amount of email addresses updated. A second process is included in this workflow that will revert the email addresses to remove the “ZZZZ” added in the first workflow. In some instances, the process may be run in error, or you may want to send emails from a Development or Testing environment; using this second process you will be able to enable all emails again.
  • The Update Email Ids workflow sets all users’ email addresses to non-working by appending a “ZZZZ” to the end of the email address. This process is used for when there are refreshes to your Development or Testing environments and do not want emails going to users. When complete, the log will display the total amount of email addresses updated. A second process is included in this workflow that will revert the email addresses to remove the “ZZZZ” added in the first workflow. In some instances, the process may be run in error, or you may want to send emails from a Development or Testing environment; using this second process you will be able to enable all emails again.
  • The Users Logged In portlet displays all users logged into the system. This portlet is helpful to determine the capacity during peak times, users still working before downtime, and the ability to view users logged in during the day. The portlet will display the resource, ID, OBS unit, OBS path, and when the user’s session was last updated.
  • The Users Logged In portlet displays all users logged into the system. This portlet is helpful to determine the capacity during peak times, users still working before downtime, and the ability to view users logged in during the day. The portlet will display the resource, ID, OBS unit, OBS path, and when the user’s session was last updated.
  • The Users Logged In portlet displays all users logged into the system. This portlet is helpful to determine the capacity during peak times, users still working before downtime, and the ability to view users logged in during the day. The portlet will display the resource, ID, OBS unit, OBS path, and when the user’s session was last updated.
  • The Auto-Approve Old Timesheets workflow process can be run through the "Execute a Process" job and may be used to quickly close out timesheets for a specified timeframe for period closure.  The workflow will execute a query that will automatically approve ALL (no matter the status of the timesheet) timesheets that have a time period start date before the Approve Date specified within the process itself.
  • The Auto-Approve Old Timesheets workflow process can be run through the "Execute a Process" job and may be used to quickly close out timesheets for a specified timeframe for period closure.  The workflow will execute a query that will automatically approve ALL (no matter the status of the timesheet) timesheets that have a time period start date before the Approve Date specified within the process itself.
  • The Auto-Approve Old Timesheets workflow process can be run through the "Execute a Process" job and may be used to quickly close out timesheets for a specified timeframe for period closure.  The workflow will execute a query that will automatically approve ALL (no matter the status of the timesheet) timesheets that have a time period start date before the Approve Date specified within the process itself.
  • The Turn off Notifications process disables all Email, SMS and Alerts notifications for all users. This process is helpful if users would not like to receive emails from the system regarding actions items, timesheet submissions, etc. The script may be modified to include all users or all users that have been created within the last day.
  • The Turn off Notifications process disables all Email, SMS and Alerts notifications for all users. This process is helpful if users would not like to receive emails from the system regarding actions items, timesheet submissions, etc. The script may be modified to include all users or all users that have been created within the last day.
  • The Turn off Notifications process disables all Email, SMS and Alerts notifications for all users. This process is helpful if users would not like to receive emails from the system regarding actions items, timesheet submissions, etc. The script may be modified to include all users or all users that have been created within the last day.
  • A presentation slide deck from Rego University 2022.  Document reviews the 7 trends that Rego is seeing in the PPM space.
    • Trend 1: Going Beyond Strategic Alignment
    • Trend 2: Pivoting Quickly
    • Trend 3: Value Scrutiny for PPM
    • Trend 4: Hybrid Financial Management
    • Trend 5: AI has the Buzz, Predictive Analytics has the Momentum
    • Trend 6: Balanced Ecosystem of Tools
    • Trend 7: Collaboration
  • A presentation slide deck from Rego University 2022.   The document reviews the process to follow post tool implementation.
    • Typical Post-Implementation / Operational Challenges
    • Aspirations for and Outcomes of a High Performing Ownership Team
    • Model Solution:
    • Roles and Responsibilities
    • Intake, Triage, and Delivery Process
    • Clarity Board-Based Solution
Go to Top