CaneLink

The Systems team, who is now a part of UMIT, manages quarterly updates that CaneLink receives from Oracle where new, innovative functionality is implemented. Additionally, the team actively researches ways to improve business processes, stays current with all delivered functionality, and continuously supports end users by troubleshooting system issues and providing them with solutions. 

More information about CaneLink, including FAQs and training tutorials, can be found on our website. Additionally, if a user is experiencing a problem with CaneLink, he or she can contact the UMIT Service Desk at help@miami.edu or 305-284-6565 for assistance.

Request for Service

All system requests are filtered through the department’s Project Manager, who coordinates the prioritization and categorization of all requests and tracks their progress.

How to Submit a Request

To submit an RFS for Systems (CaneLink): CaneLink System Request Form

(Note: Upon your initial request, you will receive a Permission Prompt. Please click “Allow” to proceed.  You will only receive this prompt once prior to the first time using the Request Form.)

UMIT Governance Approval

UMIT Governance is only included in the process if your Systems (CaneLink) request is technical in nature and requires governance approval. The Project Manager will let you know if the following form requires completion: UMIT Governance Online Form.

Definition of Terms for Systems (in alphabetical order)

  1. Action Plan: Describe the optimum proposed solution.
  2. Attachment(s): The requestor will be able to attach up to four (4) files, which will help support the system request.
  3. Comments: Feel free to add any additional comments that you feel are important that the Request Form may not directly address.
  4. Criticality: Please choose the criticality that best relates to your systems request:
    • Critical – Emergency 
      A major malfunction resulting in a product inoperative condition. Users are unable to reasonably perform their normal functions. Affects a large population of users.
    • Major – High
      Inconvenient workaround or no workaround exists. The program is usable but severely limited. Affects a high number of users.
    • Normal – Medium
      Minor feature/product failure, a convenient workaround exists. Affects multiple users.
    • Minor – Low
      Minor loss of application functionality. Affects minimal users.
  5. Description: Describe the system request in a few sentences in a way that could be understood by someone unfamiliar with the process.
  6. Drop Dead Date: Is the due date mandatory (On = Yes / Off = No)?
  7. Due Date: Requested completion date. This field defaults to a date six (6) months from the original submission date in order to provide sufficient time to review, seek approval (if applicable), prioritize and complete each request.  Depending on the completion date that is entered by the requestor, it may need to be revised by the EMSA Team due to time and/or resource limitations.
  8. Justification: Provide the justification of your systems request in terms of increased efficiency, improved functionality, new knowledge, etc.
  9. Module: Please choose the module that best relates to your systems request.
  10. Project/Task:
    • Project – Greater than or equal to 80 estimated hours of work.
    • Task – Less than 80 estimated hours of work. 
  11. Requested By: The system automatically populates this field. If you are not the “official” requestor, please include the name, office/department, email and phone of the requestor in the Comments section.
  12. Specify Pain Point(s): Describe any pain points that are caused by this issue.
  13. Title: Please provide a brief title clearly describing your systems request.
  14. Type of Request:
    • Fix Production Issue – Issue is unexpected in nature and usually requires immediate resolution. The current system is not working to specification and usually requires technical work.
    • New Functionality – A request for new features or functionality that doesn’t already exist and results in a new application being built to satisfy the request.
    • Change Request – A request that already exists, but the user wants something different.
    • Research General – More research is required for the system request.
    • Operational – Scheduled changes that occur on a regular basis in order to conduct daily business.
    • Other – Type of Request not included in this list.
    • Bundles – System updates from Oracle.
    • Unknown – Not sure of this drop-down answer.
  15. Type of Work: Please choose the type of work that best relates to your systems request.
    • Interface – Sending data from one place to another (to/from Campus Solutions).
    • Extension – Functionality not included in the delivered Campus Solutions system.
    • Customization – Enhancement to functionality that is a delivered Campus Solutions system process.
    • Report – Creating a report.
    • Other – Type of Work not included in this list.
    • Conversion – Converting from one information system to another.
    • Functional – Set up or other functionality that does not require any programmatic-type changes to Campus Solutions.
    • Query – Creating a query.
    • Data Correction – Incorrect values (in Campus Solutions) that cannot be fixed using the system and must be corrected programmatically.
    • N/A – Not Applicable
    • Unknown – Not sure of this drop-down answer.
  1.  

Contact Information

For additional questions and/or concerns regarding your request, please feel free to contact Fernando Solorzano, Project Manager for UMIT, at fas84@miami.edu.