CodeCanyon RISE - WordPress Plugin

A Practical Guide to Using and Configuring CodeCanyon RISE for Project Management, Client Work, and Support

In FairSketch's official materials, CodeCanyon RISE is described as a standalone web application for project management, CRM, invoicing, support, and team collaboration. That distinction matters for WordPress site owners: RISE is not installed through the standard Plugins section in the WordPress admin area. Instead, it is deployed separately on a server, a subdomain, or in its own directory. So this guide does not cover "how to activate a WordPress plugin." It explains how to use RISE safely alongside a WordPress project, agency website, client portal, or internal task management system.

This article is structured as a practical walkthrough: what to check before installation, how to handle the initial setup, which modules not to enable right away, how to organize projects and tasks, how to connect the client portal with billing and support, where problems usually appear, and how to identify the cause quickly. It also covers a dedicated use case for a web studio or WordPress site administrator who needs to manage clients, work items, invoices, support requests, and recurring tasks in one place.

Facts about features, server requirements, updates, the RISE plugin system, notifications, integrations, and troubleshooting are taken from the CodeCanyon listing and the RISE Docs documentation. When the original task refers to the product as a WordPress plugin but the source clearly shows otherwise, this guide does not gloss over that mismatch. It is better to catch that before installation than to waste time looking for a nonexistent Activate button inside WordPress.

What RISE Actually Is and How to Fit It into a Website Workflow

On the CodeCanyon listing, the product is named RISE - Ultimate Project Manager & CRM. The developer is FairSketch, and the technical details reference PHP, SQL, JavaScript, CodeIgniter, MySQL, and modern browsers. This is not a typical WordPress plugin with a file you upload into wp-content/plugins. RISE is deployed as a separate application. Its archive includes folders such as app, assets, files, install, system, updates, writable, along with the index.php file.

For a WordPress site owner, the practical takeaway is straightforward: RISE works best as an operations hub that lives next to your website. For example, the public site runs on the main domain, while RISE is available on a subdomain such as crm.example.com or inside a protected directory. WordPress continues to handle content, landing pages, blog posts, SEO, and forms, while RISE helps you manage clients, projects, tasks, invoices, payments, support requests, the knowledge base, internal notes, and the work calendar.

This setup is especially useful for a web agency, freelancer, service business, small support team, or someone managing multiple websites. Instead of scattering information across chat apps and spreadsheets, you can keep the client record, project, tasks, deadlines, files, invoices, tickets, and change history in one interface. At the same time, you do not need to give the client access to WordPress if all they need is visibility into project status, tasks, files, invoices, or support requests inside RISE.

The key check before you begin: if you specifically need a WordPress plugin that adds a block, shortcode, or widget to the site, RISE does not do that directly. If you need a separate workspace for managing clients and the work around the site, it is a much better fit.

How to Connect RISE with WordPress Without Pretending There Is a Native Integration

The official sources do not confirm any built-in integration between RISE and WordPress as a CMS. So the safest way to use them together is not to promise "automatic sync," but to separate responsibilities clearly. WordPress collects leads, publishes pages, and serves as the public-facing site. RISE handles the operational side: who the client is, what needs to be done, which tasks are open, which invoices have been issued, and which support requests are already closed.

In practical terms, you can organize it like this:

• A WordPress form sends inquiries to a work email address, and RISE can turn incoming messages into tickets through its ticket settings and IMAP, if that workflow is enabled and configured correctly.
• The RISE client portal replaces WordPress access, so the client can view project files, tasks, invoices, and the knowledge base without getting unnecessary permissions on the public website.
• Links from WordPress point to RISE only where that makes sense, such as the client login page, knowledge base, or a public form, if it is enabled in your installation.
• Reporting stays inside RISE, because tasks, statuses, timers, invoices, payments, and tickets belong to operational work, not to the WordPress engine itself.

This does not turn RISE into a WordPress extension, but it does create a stable architecture: the website is not overloaded with CRM features, and your operational workflows do not depend on the theme, cache, block editor, or WordPress updates.

Who RISE Is a Good Fit For and When Another Type of Tool Makes More Sense

RISE is worth considering when you already have a steady flow of clients, tasks, invoices, support requests, and internal work that no longer fits inside ordinary email. The product covers several areas at once: CRM, project management, tasks, a Kanban board, a client portal, invoices and payments, support, a knowledge base, team roles, notifications, calendar, files, and additional modules. That breadth is valuable when you need a business operating system, not just a single widget on a site.

For a WordPress agency, RISE can become the central layer between sales, production, and support. A lead comes in through the website, the manager creates a client, then a project, the team receives tasks, the client sees the status, accounting issues the invoice, support handles the ticket, and the owner reviews project, payment, and workload summaries. That is not a single WordPress plugin use case. It is the operational framework around the site and the team.

When the Product Is a Strong Choice

RISE is especially useful in cases where you need more than task management alone and want client communication and finances tied in as well:

• A web studio or SEO team manages website projects, coordinates tasks with clients, stores files, sends invoices, and handles support requests.
• A freelancer with multiple clients wants to track tasks, deadlines, invoices, communication, and payments without stitching together a stack of separate services.
• A service company supports clients through tickets, a knowledge base, and internal responsibility roles.
• A small business wants a self-hosted CRM workspace on its own server instead of relying only on an external SaaS platform.
• A development team wants to link GitHub or Bitbucket commits to tasks by including the task ID in the commit message.

When RISE May Be More Than You Need

This is not a product to install "just in case." If you have one simple website, no team, no client projects, no invoices, and no support workflow, RISE will add more administration than value. It requires server resources, a database, updates, backups, email setup, and team discipline. For a single contact form or a handful of tasks, a WordPress form plugin, a lightweight CRM integration, or a task board is enough.

RISE also does not replace a full WooCommerce customer account area if you need deep order handling inside an online store. It can manage invoices, clients, tickets, and projects, but it should not be used as a substitute for the cart, checkout, inventory, or customer account area of a WordPress store unless you have a confirmed integration.

What This Guide Helps the Reader Figure Out

Search intent around a product like this usually goes far beyond "download CodeCanyon RISE." People want to know how to configure RISE after installation, how to use it for project work, how to enable the client portal, how automatic ticket creation from email works, which installation and update problems are common, how to verify cron, how RISE compares with Perfex CRM or Worksuite, and whether it can be used alongside WordPress. Those questions shape the structure of this guide.

What to Check Before Installing It on a Server

Preparation matters more than the installation itself. RISE stores real working data: clients, tasks, invoices, files, tickets, and settings. If you deploy it on unsuitable hosting, skip backups, or fail to verify mail features, the problems will show up only after your team has already started using the system.

FairSketch documentation lists the server requirements: PHP 8.1 or higher, MySQL 8.x or MariaDB, plus the MySQLi, cURL, mbstring, OpenSSL, GD, intl, json, mysqlnd, xml, and fileinfo extensions. It also notes that zlib.output_compression must be disabled. For cloud hosting, the documentation gives a baseline resource guideline of 1 vCPU, 2 GB of memory, and 10 GB of storage. Those numbers do not replace proper capacity planning, but they are useful for ruling out underpowered hosting plans.

Domain, Subdomain, and Installation Location

In the quick installation guide, the developer recommends installing RISE on a main domain or subdomain rather than burying it deep inside a folder structure. For a WordPress setup, a subdomain is usually the most practical choice: crm.example.com, portal.example.com, or projects.example.com. It is easier to manage SSL, access rules, backups, and separate server policies that way. A directory inside a WordPress site may work technically, but it creates more overlap with URL rewrite rules, cache behavior, file structure, and security policies.

Do not install RISE inside WordPress directories such as wp-content or wp-admin. That is not just inconvenient. It also makes maintenance riskier. A separate application directory with its own database and a clear URL reduces the chance of accidental conflicts.

Database and Backups

Before installation, create a separate MySQL or MariaDB database, a separate database user, and keep only the details the installer actually needs: database name, username, password, and host. Do not reuse the WordPress database user unless you have a compelling reason. Separation makes rollback, migration, troubleshooting, and permission control much easier.

Decide up front where backups will be stored. In RISE, it is not just the SQL tables that matter. Files matter too: project attachments, documents, images, uploaded materials, logs, and settings. FairSketch's update instructions explicitly remind users to back up both files and the database before installing new versions. That rule should apply not only to updates, but also to your first experiments on a live domain.

Email, SSL, and Automation

RISE depends heavily on notifications, email templates, tickets, invoices, and client access. Before you invite the team in, verify the following:

• An SSL certificate for the domain or subdomain, especially if you plan to use push notifications, client logins, and public forms.
• Outgoing email, so invoices, invitations, notifications, and tickets do not disappear into a void.
• IMAP or a mail service API, if you want to create tickets from incoming email.
• A cron job, because some recurring tasks and automated actions depend on the scheduler.
• Hosting limits related to memory, execution time, write permissions, and access to external APIs.

Short version: installing RISE takes less time than preparing a proper environment for it. But that preparation is what determines whether the system will run reliably with tasks, email, tickets, files, and updates.

Installation and Initial Validation Without Mixing It Up with WordPress

The RISE installation process is much closer to deploying a PHP application than installing a WordPress plugin. You upload files to the server, create a database, open the application URL in a browser, go through the requirements check, and enter the administrator details. At this stage, there is no reason to log into WordPress, look for Plugins, or try uploading the archive through the standard WordPress installer.

FairSketch documentation outlines the typical sequence: extract the archive, upload the files to the server, create a MySQL database, open the installation URL, check the requirements, enter the database settings, create the administrator account, wait for the tables and configuration to be created, and then delete the install folder. That last step is critical: the installation directory must not remain accessible after setup is complete.

Basic Installation Sequence

1. Prepare a subdomain or separate directory and make sure it does not contain WordPress files.
2. Upload the contents of the RISE archive so the folder structure matches the documentation: app, assets, files, install, system, updates, writable, index.php.
3. Create the database and a database user with sufficient permissions for installation.
4. Open the application URL in your browser. If everything was uploaded correctly, you should see the installation screen and the server requirements check.
5. Enter the database settings and administrator details. Use a real working email address, since it will be needed for system notifications.
6. Wait for the installation to finish, and only after you can log in successfully, delete the install folder.
7. Test the login in both a regular browser window and a private window to make sure sessions, SSL, and the URL behave correctly.

What to Check Right After the First Login

The first successful login does not mean the product is ready for production. At this stage, do not invite the whole team yet. First, run a short sanity check of the installation:

• The dashboard opens without errors, menu items are accessible, and the page does not collapse into a blank screen.
• The logo, language, application name, and basic settings can be saved without write errors.
• A test email is sent from the server, if you have already configured SMTP or another mail mechanism.
• File upload works in a test project or another safe location, assuming the allowed file formats are configured.
• The administrator can create a role, a client, and a project, then sign out and open them again after logging back in.

If you see write errors, a blank screen, or settings that will not save at this stage, do not keep loading data into the system. Turn on troubleshooting first, check file permissions, verify PHP requirements, and review the logs. The earlier you catch the issue, the easier it is to roll the installation back cleanly.

Post-Installation Setup: Turning a General Dashboard into a Working System

RISE does not become useful the moment its files are uploaded. It becomes useful after it is configured. The Getting Started Guide lists the core setup areas: app settings, email settings, disabling unneeded modules, notification settings, cron job, inviting the team, roles, clients, projects, invoices, and support tickets. In practice, this is not one screen. It is a sequence of decisions: what the team will manage, what the client will see, which notifications matter, and which processes should be automated versus handled manually.

Do not enable every module just because it exists. The broader the system becomes, the more effort it takes from the team, and the greater the chance that users will ignore sections they do not need. It is better to start with a minimal working setup, test it with one client, and only then add payments, the store, advanced support, AI Assistant, Slack, Pusher, GitHub, or Bitbucket.

General Application Settings

Start with the sections that every user will see: the application name, logo, language, file format settings, the number of rows in lists, appearance, and other basic parameters. The CodeCanyon listing says RISE lets you change themes, add custom styles, configure languages, email templates, custom pages, and the left menu. The documentation also covers custom dashboards and the left menu separately.

For a typical first setup, it is enough to:

• Set a clear workspace name, so users do not confuse a test installation with the live one.
• Upload a logo and favicon, as long as it does not break rendering and the file formats are allowed.
• Keep only the modules you actually need, so the menu does not turn into a maze.
• Configure email templates for invitations, invoices, tickets, and notifications without deleting system variables unless you fully understand their role.
• Review the left menu for the team and separately for the client portal, if clients will log into the system.

Roles and Permissions

Roles in RISE are not decorative. The Roles & Permissions documentation makes it clear that different team members should only see and control the part of the workflow that belongs to them. For a web studio, that matters especially: the manager works with the client and the invoice, the developer sees tasks and files, accounting handles invoices, the client sees only their own portal, and a contractor may need limited access to one specific project.

Start by sketching a simple role matrix on paper or in a document:

• Administrator manages settings, users, updates, and critical modules.
• Project manager creates clients, projects, tasks, and milestones, tracks deadlines, and communicates with the client.
• Contributor works with tasks, comments, files, and time, but does not change financial settings.
• Finance manages invoices, payments, taxes, and reports, if that part of the system is in use.
• Client sees only the allowed projects, tasks, files, invoices, tickets, and knowledge base.

After saving the roles, test each one with a separate test user. Do not trust the configuration until you have seen it through the user's eyes. The expected outcome is simple: each person sees exactly the sections they need for their work and cannot access someone else's projects, invoices, or settings.

The Client Portal

The client portal is one of the main reasons to use RISE alongside WordPress. The documentation describes a dedicated client dashboard, Client Permissions settings, the Client Portal Dashboard, and the Client Portal Left Menu. This makes it possible to give the client access to project status without giving them access to WordPress or sending reports manually.

The best way to configure the portal is in three steps. First, decide whether the client needs a login at all. Then enable only the permissions they actually need, such as access to projects, tasks, files, invoices, or tickets. After that, arrange the client's left menu so the most common actions appear first instead of exposing the entire module list.

How to verify it: create a test client and a test project, add the client to the project, log in as the client user, and confirm that they cannot see internal notes, other clients' tasks, financial settings, or the administrative menu.

Notifications, Email, and Communication Channels

RISE supports web notifications and email notifications, and the documentation suggests Pusher for push-based setups. It also describes a Slack integration where notifications can be sent to a selected channel through an incoming webhook. At the beginning, do not enable everything. First define which events truly deserve attention: a new task, a client comment, a new ticket, an invoice, a status change, or a deadline.

If there are too many notifications, people will start ignoring them. Configure notifications by role: the client needs events related to their project and invoices, the manager needs new tickets and important changes, the contributor needs assigned tasks and comments, and the administrator needs system errors and critical events. After setup, trigger test events and verify where they appear: the top bar, email, Slack, or Pusher.

Projects, Tasks, and Kanban: Building a Daily Team Workflow

RISE is strong not just as a CRM, but also as a project system. The CodeCanyon page lists tasks, assignees, collaborators, a Kanban board, milestones, comments, checklists, progress calculation, time tracking, reminders, and change logs. Older public documentation also explains how progress works: it is calculated from completed and incomplete tasks with points taken into account. That matters because project progress should not be a decorative bar. It should reflect the real task structure.

If you manage WordPress projects, do not create one giant project called "Client Website" with dozens of unrelated tasks. It is much better to break the work into milestones or meaningful stages: preparation, design, development, content, SEO review, launch, and support. Then both the client and the team can see not just a to-do list, but the actual stage the project is in.

The Project Record

A project record should answer four questions: what are we doing, for whom, who is responsible, and how do we know the work is complete. In RISE, a project is tied to the client, participants, tasks, files, comments, and deadlines. If you do not assign the client or add project members, access may be incomplete. The documentation explicitly notes that only project members get access to projects.

A minimal project record for a WordPress agency might include:

• Project name: not just the domain, but also the type of work, such as "example.com catalog redesign."
• Client: the company or contact who owns the project.
• Project members: the manager, designer, developer, SEO specialist, and client contacts, if they should be able to see tasks.
• Milestones: stages that make progress easier to track.
• Files: the brief, access instructions, mockups, and reports, but without storing secrets in open comments.

Tasks and Statuses

A Kanban board is only useful when the statuses reflect the real workflow. For a small team, a simple chain is enough: new task, in progress, in review, done. If you add too many columns, people will move tasks around arbitrarily. If you keep only "in progress" and "done," the manager loses the review stage.

For each task, use more than just a title. Add context: the link to the WordPress page, the expected outcome, the acceptance criteria, who is reviewing it, where the file or access details are stored, and whether it depends on the client. If the task is recurring, review the recurring task settings, but remember that RISE documentation ties recurring tasks to cron.

How to Evaluate Project Progress

Progress becomes useful when tasks are broken down enough and statuses are used honestly. For example, a task called "Build the site" is meaningless for progress tracking. Tasks like "Configure the contact form," "Test email delivery," "Add the services page," and "Check the mobile menu" contribute clearly to the overall outcome. After some of those tasks move to Done, progress should change in a way the manager can actually explain.

Time, Comments, and Files

The Timesheets documentation describes three ways to track time: a start/stop timer, a time range with a start and end, or manual entry of the total hours and minutes if the administrator has allowed that mode. For an agency, this helps separate actual work measurement from the feeling that "we did a lot." Time logged against tasks can then be used for profitability analysis, invoicing, or capacity planning.

Comments and files should document the history of the solution, not replace the task itself. A good pattern is this: the task captures the goal, the comments capture the work in progress and questions, the files hold the materials, and the status reflects the current state. If the discussion drifts too far, create a new task or ticket so the original thread does not lose its meaning.

Clients, Invoices, and Support: Connecting CRM to Real Requests

In RISE, the CRM layer is not separate from project work. The CodeCanyon page lists clients, invoices, payments through PayPal, Stripe, Paytm, or cash, subscriptions, estimates, support tickets, email-to-ticket, a knowledge base, contracts, the client portal, files, and folders. For a WordPress site owner, that means inquiries, service work, and documents can all be managed alongside projects instead of being spread across different systems.

But this is also the area where an installation is easiest to overload. If you do not issue invoices through RISE, do not start with payment settings. If support still runs through personal email, do not enable IMAP without a test mailbox. If clients do not need a portal yet, do not expose it before permission checks are complete. Otherwise, you end up with half-working workflows that are difficult to explain to the team.

The Client Record and Contacts

Create the client before the project if you want the full work history in one place. For a company with multiple contacts, it is important to separate responsibilities: who approves deliverables, who receives invoices, who handles technical questions, and who creates tickets. Recent RISE changes mention the ability to select an existing contact when adding a contact to a client, along with fixes and improvements related to client files and access.

Do not give every contact the same permissions. For example, the client's accountant may need access to invoices but not to technical tasks. The person responsible for the website may need access to the project and tickets, but not to internal financial reports. That level of care takes time, but it reduces the risk of giving people more access than they should have.

Invoices and Payment Links

The documentation for paying invoices without logging in describes a setup where the client can pay an invoice through a direct link in the email, provided the relevant option is enabled in settings and the email template includes the {PUBLIC_PAY_INVOICE_URL} variable. That is useful when the client does not want to sign into the portal every time. But you should enable that workflow only after checking the email template, payment methods, and access rules.

In a web studio workflow, an invoice should be tied to a clear stage: deposit, milestone completion, monthly support, a change request, or an audit. If invoices are created without any connection to the project and tasks, RISE becomes just another document list instead of a system for managing work.

Email-to-Ticket and the Knowledge Base

One of RISE's strongest support features is automatic ticket creation from incoming email through IMAP. The documentation explains that the system creates tickets from unread emails, marks them as read, and for replies to the same ticket, checks the ticket ID in the email subject. If the ID is missing, the message is treated as a new ticket. Both clients and staff need to understand that behavior, otherwise duplicate tickets will start appearing.

Before enabling the IMAP workflow, create a test mailbox and verify the following:

• The integration status changes to Authorized, if the correct settings or API are being used.
• New emails turn into tickets, while already read messages do not create extra records.
• A reply to an existing ticket keeps the ID in the subject, otherwise the thread may split apart.
• Email templates do not remove the internal variables needed to connect the reply back to the ticket.

The knowledge base is most useful not for generic filler articles, but for recurring questions: how to share access, where to check project status, how to approve a mockup, how to submit a revision request, and what information is needed before a site launch. When the client can read a clear article first and create a ticket only for a real issue, support becomes calmer and more efficient.

Automation, Integrations, and AI Assistant: What to Enable Only After the Basics Are Proven

RISE supports several layers of automation: cron jobs, recurring tasks, recurring invoices, calendar events, email-to-ticket, Pusher, Slack, Google Calendar, GitHub, Bitbucket, and AI Assistant. That looks appealing, but every integration adds a dependency: an external service, keys, webhooks, permissions, limits, SSL, server configuration, and possible failure points. So enable them as needed, not all at once.

Cron Jobs and Recurring Actions

The cPanel documentation explains that a cron job is required for functions marked with a note that the scheduler is necessary. A separate recurring tasks article says recurring tasks depend on cron. This is a common source of trouble: the administrator enables recurrence, but no new tasks are created because cron is not configured or does not run often enough.

The check is simple: copy the cron command from Settings > App settings > Cron job, add it in your hosting control panel, and create a test automation that should appear without any manual trigger. If nothing happens, check the PHP path, execution permissions, logs, and hosting limits.

Slack, Pusher, and Browser Notifications

The Slack integration in the documentation is built through a Slack App and Incoming Webhooks: you create an app in Slack, enable the webhook, choose a channel, and add the URL in RISE. Pusher is used for push notifications, and the documentation specifically notes its dependence on web notifications and HTTPS. If the site is not served over a secure protocol, notification behavior may differ from what you expect.

Start by enabling web and email notifications inside RISE itself. Then add Slack for the events that genuinely need a team channel. Leave Pusher for a later stage, once the basic notifications already work, because otherwise it becomes hard to tell whether the problem is in RISE, the browser, SSL, Pusher, or user settings.

GitHub and Bitbucket for Development Tasks

RISE can receive commit logs into task activity logs through GitHub and Bitbucket. The GitHub Integration documentation says you need to enable the integration in Settings > App Settings > Integration > GitHub, copy the webhook listener link into the repository settings, and include a # symbol plus the task ID in the commit message to connect a commit to a task. The example in the documentation is Task #10.

For a development team, this is useful only if people write commit messages consistently. If the task ID does not make it into the message, RISE cannot tie the technical change to a specific task. That is why this rule should be part of the project's working guidelines: every commit related to a task includes the RISE task ID.

AI Assistant Without Inflated Expectations

The changelog for the latest current RISE version adds AI Assistant, ChatGPT and Gemini integrations, AI agents, an AI chatbox, a quick assistant, and AI-powered ticket replies. The documentation also draws an important boundary: answer quality depends on the provider, model, training data, system instructions, and context, and RISE does not validate or correct AI output. So AI Assistant is best used as a drafting helper for quick replies and knowledge base work, not as an autonomous support employee.

For a safe rollout, create a separate agent for internal testing only, train it on a limited set of materials, test its replies on typical tickets, and do not allow generated responses to go to clients without human review. If you turn on automation without editorial review, you can quickly end up with polite but inaccurate answers.

Practical Example: Managing a WordPress Website Maintenance Project in RISE

Below is a real-world example rather than an abstract business case: a web studio maintains a client's WordPress website, accepts requests, plans improvements, issues invoices, and handles support. The goal is to show how to turn RISE's feature set into a clear working process.

The Goal of This Setup

You want one workspace where the manager can see the client, the website project, team tasks, support requests, files, tracked time, and invoices. The client does not get access to WordPress, but can still view the approved parts of the workflow through the RISE client portal.

Preparation

Before you begin, the basic conditions should already be in place:

• RISE is installed on a separate subdomain and opens over a secure URL.
• Roles are created for the administrator, project manager, contributor, and client contact.
• Email has been verified, and a test notification reaches the user.
• The client portal is configured so the client sees only their own projects, files, invoices, and tickets.
• The cron job works, if you plan to use recurring tasks, reminders, or other automated actions.

Project Setup Steps

1. Create the client with the company name, working contacts, and primary email address.
2. Add a project for the specific site, such as "example.com support and growth." Link the project to the client.
3. Add project members: the manager, developer, content editor, and the client contact if that person is allowed to see tasks.
4. Create milestones: "Monthly Support," "Critical Fixes," "Content Updates," and "Technical Optimization."
5. Create the first tasks: check WordPress backups, update plugins on a site copy, test the contact form, fix the mobile menu, and prepare a report.
6. Configure Kanban statuses so each task moves through "New," "In Progress," "In Review," and "Done."
7. Add the technical brief as a file and document where access credentials are stored. Secrets are better kept in a dedicated password manager, with only a link or access note left in RISE.
8. Create a test ticket from the client side or through email-to-ticket to verify the request path.
9. Create a test invoice or invoice draft if the finance module is part of your workflow.

Checking the Outcome

After the setup is complete, log in under each user type:

• The project manager should see the project, tasks, client, files, tickets, and reports needed for management.
• The contributor should see assigned tasks and be able to leave a comment, upload a file, or log time if allowed.
• The client should see only their own project, approved tasks, files, invoices, and tickets, with no internal settings or other clients' data.
• The administrator should have access to settings, updates, roles, notifications, and logs.

A good outcome means each participant understands where to look, where to leave a comment, where to check status, where to see an invoice, and how to create a request. If the client gets lost in the menu, go back to the Client Portal Left Menu settings and remove extra items. If a staff member cannot see the project, check project members and the assigned role. If an email does not create a ticket, inspect IMAP, email subject templates, and the integration status.

A Common Friction Point

Teams often try to use RISE for the project, chat, support, and finance all at once, but never agree on the rules. As a result, some tasks stay in messenger apps, some live in comments, and others sit in tickets. Before launch, set one simple rule: if an action requires a response or verification, it must exist as a task or a ticket, not just as a chat message. That keeps the work history from falling apart.

How to Confirm the System Is Working Properly After Setup

Your validation should not be formal or superficial. It should resemble a real workday. Simply opening the dashboard is not enough. You need to walk through the system as the client, manager, contributor, and administrator, because RISE connects several roles. A problem visible to one role may be invisible to another.

Administrator Validation Pass

The administrator checks the technical side:

• Settings save correctly and do not reset after the page reloads.
• Write permissions work, files upload correctly, and attachments open.
• Email sends successfully, and templates do not have required system variables removed.
• The cron job runs, and automated functions actually fire.
• Logs are available in writable/logs, if troubleshooting is enabled.
• The install folder has been removed, and the installation screen no longer opens.

Manager Validation Pass

The manager checks the workflow itself:

• A new client can be created, the contact is saved, and the right invitations are sent.
• The project is linked to the client, and project members have access.
• A task moves through the Kanban flow and keeps its comments, files, deadline, and assignee intact.
• A ticket is created and receives a reply, and the email history does not split into duplicates.
• An invoice or estimate is visible where it should be, and hidden from users without permission.

Client Validation Pass

The client login often reveals issues the administrator misses. Check the portal in a private browser window: does it show only one client, do the approved projects open, are the menu labels clear, are there any internal names, technical test tasks, or someone else's files? If public invoice payment links are enabled, test them separately without logging into the portal.

Launch rule: do not move real clients into RISE until a test client has completed the full path from invitation to task, ticket, file, invoice, and notification.

Safe Improvements and Ongoing Maintenance Without Editing Core Files

RISE offers personalization features and a plugin architecture, but that does not mean you should edit the application core. The developer explicitly provides plugin hooks and an extension system, and the documentation warns that third-party plugins are supported by their own authors. So the safest strategy is this: settings first, built-in features second, a separate plugin or documented hook only when truly necessary, and core edits only as a last resort for a developer who understands the risk of losing changes during updates.

Updates Only After a Backup

The RISE update instructions say that files and the database should be backed up before an update. They also note that when several version updates are involved, they need to be installed in sequence, and automatic updates depend on the application directory being writable. For a production installation, that means:

• Back up the database and files first, then update.
• Use a copy or staging environment first, if you have custom changes or third-party plugins.
• Apply updates in sequence, if the system offers multiple steps.
• Check login, tasks, tickets, invoices, and files after the update.

When to Change the Minimum Cron Interval

The documentation describes the minimum_cron_interval_seconds parameter in app/Config/App.php. By default, the minimum interval is set to avoid unnecessary load. If you genuinely need more frequent processing, you can change the value, but only after evaluating the server capacity.

The documentation example looks like this:

public $minimum_cron_interval_seconds = 60;

This is not a universal recommendation to "set it to 60." On a small shared hosting plan, running cron too frequently can create extra load. The safe approach is to change the value on a copy or during a low-traffic window, review the logs, make sure cron is not running too often in parallel, and restore the previous value if the server starts responding more slowly.

If AI Assistant Replies Are Getting Cut Off

The AI Assistant documentation describes an issue where streaming responses may break on servers using Nginx and PHP-FPM because of buffering. As a server-side fix, it suggests disabling FastCGI buffering for the PHP location. This kind of change should be applied only by a server administrator who understands the Nginx configuration:

location ~ \.php$ {
    fastcgi_buffering off;
    gzip off;
    add_header X-Accel-Buffering no;
}

After the change, you should reload Nginx and confirm that standard RISE pages, login, tickets, and AI Assistant still work correctly. If you do not manage the server yourself, it is better to pass this snippet to your hosting provider or system administrator. To roll it back, restore the previous configuration block from a backup.

RISE Extensions and Custom Plugins

RISE has its own plugin system, but it belongs to RISE, not to WordPress. The documentation describes installation through Settings > Plugins, the correct ZIP structure with a single root folder and index.php, plus hooks and functions for developers. This is useful if you need to add a menu item, dashboard widget, email template, notification config, payment method extension, ajax tab, or another extension without modifying the core.

If you are not a developer, do not install random extensions just because they are available on a marketplace. Check whether the plugin is compatible with your RISE version, who supports it, which database tables it creates, whether it can be disabled without data loss, and whether there are clear update instructions. FairSketch documentation also explicitly states that third-party plugins are not developed or supported by FairSketch.

Personalizing RISE: Menus, Dashboards, Fields, and Email Templates

One of RISE's strong points is not just its list of modules, but the ability to shape the interface around the way your team actually works. The CodeCanyon page mentions ready-made themes, custom styles, drag-and-drop left menu configuration, custom fields, language settings, email templates, custom pages, and feature toggles. The documentation also covers Custom dashboards, Customize left menu, Custom fields, and Email templates in separate sections. These settings may seem secondary, but they often determine whether the team will actually use the system every day.

If you leave the menu and dashboard untouched, users may be confronted with too many sections at once. That is fine for an experienced administrator, but for a client or a new team member, it is just noise. Personalization is not about looks. It is about shortening the path to action: the manager immediately sees projects, tickets, and invoices; the contributor sees assigned tasks and comments; the client sees the project, files, invoices, and support; the owner sees a summary of workload and money.

Dashboards by Role

The Custom dashboards documentation explains how to create multiple dashboards, choose a grid, and position widgets with drag and drop. It also notes that a custom dashboard is private to the user, while the administrator can replace the default dashboard for everyone. In practical terms, that means one screen should not try to solve everything.

For a web studio, you could create three dashboards:

• The manager dashboard with open projects, tasks awaiting review, new tickets, upcoming deadlines, and invoices ready to send.
• The contributor dashboard with assigned tasks, comments, time entries, and files for current projects.
• The leadership dashboard with an overview of projects, payments, expenses, team workload, and problem tickets.

Do not try to enable every widget immediately. If the dashboard turns into a long stream of panels, the user ends up hunting through the menu again. A good dashboard answers one question: "What needs my attention right now?" and gets the user to the next action in one or two clicks.

How to Validate the Dashboard

The check is simple: assign the user a role, open the dashboard, and ask them to find three actions without guidance. The manager should quickly spot a new ticket and an overdue task. The contributor should find an assigned task. The client should understand where the project is and where to find the invoice. If the user has to ask where to click, the dashboard is overloaded or the menu does not match the role.

The Left Menu for Team Members and Clients

The Customize left menu documentation describes three important use cases: the global menu for admin and team members, the personal menu in My profile > My Left menu, and the separate client portal menu in Settings > Client portal > Left menu. That means you can do more than just reorder items. You can also turn them into submenu items or top-level menu entries.

For the internal team, the sections used every day should stay at the top: Projects, Tasks, Tickets, Clients, Sales, or Reports, depending on the role. For the client, the menu should be even shorter. If the client sees Projects, Files, Invoices, Tickets, and the Knowledge base, that is often enough. Sections the client does not understand or will never use are better hidden than explained in a separate instruction sheet.

Custom Fields Without Turning the Data into a Mess

The Add custom fields documentation says custom fields can be added in many contexts, configured for role-based visibility, hidden from clients, made non-editable for clients, marked as required, used in multilingual mode, and shown or hidden in list view. That is powerful, but also easy to misuse.

Add custom fields only for data that is genuinely used in reporting, filtering, validation, or day-to-day team work. For example, in WordPress projects, fields such as "Site type," "Testing environment," "Content owner," "Next maintenance date," or "SLA priority" may be helpful. But there is no reason to create dozens of vague fields such as "Comment 1," "Comment 2," or "Other." Those quickly become junk.

The right chain of questions for a custom field is this: what decision depends on this field, who fills it in, who can see it, where it appears, whether it must be required, and what happens when it is wrong. If a field is useful to only one manager and does not affect the workflow, it may belong in a note rather than as a structured field.

Example Custom Fields for WordPress Maintenance

For a website support project, you can add a few fields if they genuinely help the workflow:

• Environment type: production, staging, or local, so the contributor knows where to validate the task.
• Priority level: normal, urgent, or blocking, so the manager can sort tasks by risk.
• Client review required: yes or no, so tasks are not closed before approval.
• Related domain: useful when the client manages multiple sites and one project covers different URLs.

Make sure the client cannot edit fields tied to internal evaluation, and that required fields do not get in the way of creating urgent tasks quickly. If there are too many required fields, the team will start working around the system by putting information into comments instead.

Email Templates as Part of the Workflow, Not Decoration

The Email templates documentation says templates can be edited in Settings > App settings > Email templates, language variants can be added with the plus button, code can be edited through the </> icon, variables can be used, and the system template can be restored through Restore to default. This area requires care: an email can look better visually while quietly breaking because a variable that builds the link, name, signature, or internal identifier was removed.

Before editing an email, define the purpose clearly. For example, a client invitation should explain why the portal matters and what the person will see after logging in. An invoice email should include clear payment context and a link, if you have enabled payment without login. A ticket reply should preserve the subject line and internal elements so the thread does not split into new tickets. After editing, send test emails to several mail services and check not only the appearance, but also the links and their behavior.

How to Choose and Disable Modules So RISE Does Not Become Overloaded

RISE covers a wide range of functions: clients, projects, tasks, leads, sales, tickets, invoices, payments, calendar, messages, notes, team members, reports, a knowledge base, files, and extensions. A large feature set is useful when each part is tied into the workflow. But if you enable everything at once, the team does not get a management system. It gets a warehouse of capabilities where it is hard to tell what is required and what is just experimental.

In the Getting Started Guide, the developer explicitly recommends unchecking modules you do not need. It is a simple but important recommendation. Disabling extra modules is not limiting the product. It is how you make the starting point manageable. First launch the core: clients, projects, tasks, roles, email, notifications, and the portal. Then add invoices, tickets, the knowledge base, recurring tasks, integrations, and AI Assistant only if they are genuinely needed.

The Minimum Viable Starting Set

For a WordPress agency or support team, start with this setup:

• Clients, so every piece of work is tied to a specific customer.
• Projects, so support, development, and one-off improvements are not mixed together.
• Tasks, so each work item has an assignee, a status, a deadline, and a definition of done.
• Files, so project materials stay in the right context.
• Tickets, if client requests need to enter a support workflow.
• Invoices or estimates, if financial documents are truly being managed inside RISE.
• Knowledge base, if you are ready to maintain useful articles rather than an empty section.

Everything else can be added later. For example, Google Calendar is useful when the team already manages events in RISE. Slack matters only if team channels are actively used for work notifications. GitHub or Bitbucket make sense only in development workflows where commits are consistently tied to task IDs.

Which Modules Are Better Left Until After the First Test Month

After the first month of real use, you will have actual data: which tasks repeat, what clients ask about most often, where deadlines slip, which notifications get ignored, and whether invoices and payments are easier to manage elsewhere. That is the right point to turn on more advanced functions. Recurring tasks are worth adding when you have a clear set of repeating jobs: update checks, backups, reports, monitoring, or certificate renewals. AI Assistant is worth testing when you already have a solid knowledge base and a person responsible for reviewing answers. Pusher and Slack are worth enabling when you clearly understand which events truly require immediate attention.

If a feature did not change team behavior, it is usually better to disable it or remove it from the menu. A module is useful not because the product includes it, but because enabling it made a specific action easier to perform, easier to verify, or less prone to manual error.

The "Do We Actually Need This Module?" Check

For every debatable module, ask five questions:

1. Which role will use this module every week? If there is no answer, it is too early for that module.
2. What input triggers the work? For example, a client email, a new task, a due date, or a new invoice.
3. What output should appear inside RISE? A ticket, task, event, invoice, comment, notification, or file.
4. How will you verify that the module works? There should be a test workflow, not just an enabled toggle.
5. What happens if the module is turned off? If nothing changes, it is not part of the actual process.

This approach protects you from a common mistake: installing a heavy system and using it like an expensive notebook. RISE becomes powerful when each module has an owner, input data, a clear outcome, and a way to validate that it is working.

Troubleshooting Common RISE Problems

Most RISE problems are not caused by a single button. They usually come from the environment: server requirements, file permissions, email, cron, roles, the portal, third-party plugins, updates, or integrations. Below is a practical map of symptoms, likely causes, and what to check. It does not replace the logs, but it helps you choose the right direction quickly.

An Error or Blank Screen Appears After Installation

Symptom: the installer finishes, but the dashboard does not open, the page is blank, or a server error appears. Possible causes include an unsupported PHP version, a missing extension, incorrect write permissions, a database configuration issue, or a problem with the uploaded files.

What to check: the RISE server requirements, installed PHP extensions, database availability, permissions for writable, files, and configuration files, plus the logs. The debugging documentation recommends enabling the error log in app/Config/Logger.php and checking the files in writable/logs. Development mode should be enabled on a live site only temporarily and turned off again after testing.

How to fix it: bring the server in line with the requirements, restore any missing files from the archive, verify the database settings, correct the permissions, and try logging in again. If the error appeared after a configuration change, roll back the most recent change first.

Recurring Tasks or Reminders Are Not Running

Symptom: recurring tasks are enabled, but new tasks do not appear, and reminders or automated actions do not fire. The likely cause is that the cron job is not configured or the cron command is failing.

What to check: the command in Settings > App settings > Cron job, the PHP path in the hosting panel, the cron execution log, the minimum run interval, and any server restrictions.

How to fix it: configure cron according to your hosting provider's instructions, run a test automation, and review the log. If you changed the minimum interval in app/Config/App.php, temporarily restore a more conservative value and watch the server load.

Emails Are Not Turning into Tickets or Replies Create Duplicates

Symptom: a client emails the support address, but no ticket is created, or a reply to an existing ticket becomes a new request. The cause may be the IMAP settings, authorization status, whether the email was already read, the subject line, or the templates.

What to check: IMAP integration status, mailbox access, unread status of the emails, presence of the ticket ID in the reply subject, email templates, and Gmail or Outlook limitations. The documentation makes it clear that without the ticket ID in the subject, the email is treated as a new ticket.

How to fix it: restore the email subject template, verify the app password or API connection, send a fresh unread message to a test mailbox, and trace how it arrives in RISE.

The Client Cannot See the Project, Tasks, or Files

Symptom: everything is visible in the admin area, but the client user sees an empty portal or cannot open the required project. Possible causes include the client contact not being added to the project, task visibility not being enabled, the relevant portal menu item being hidden, or the client role being too restricted.

What to check: Settings > Client portal > Client permissions, project members, the Client contacts section in the project, the client portal left menu, and the user's specific role.

How to fix it: add the client contact to the project, enable the required permissions, test the portal in a private window, and do not broaden access beyond what is necessary.

Notifications Go to the Wrong Place or There Are Too Many of Them

Symptom: users complain about a flood of emails, Slack receives unnecessary events, and important notifications get lost. The cause is usually notification settings that are too broad or roles that were never mapped to real responsibilities.

What to check: the events in notification settings, enabled web/email/Slack channels, Pusher, recipient roles, and test events for each user type.

How to fix it: reduce notifications to the events that matter for actual work, split them by role, keep Slack for team-level events only, and use web or email for personal notifications.

The Update Fails or Permission Errors Appear

Symptom: RISE detects an update, but the installation does not complete, or some functions break afterward. The update documentation reminds you to back up files and the database, install multiple updates in sequence when required, and make sure the application directory is writable.

What to check: the backup, write permissions, whether multiple updates are pending, third-party plugins, and any custom code changes.

How to fix it: restore the backup first or test the update on a copy of the site. If you have custom changes, use manual merging through a repository as the documentation recommends, or hand the work to a developer. Do not overwrite a working installation without a backup.

Video on Roles and Permissions in RISE

FairSketch documentation includes a focused RISE CRM video on creating roles and assigning permissions. It supports one of the core points in this guide: before inviting your team, you should not just create users, but also define who can see projects, clients, invoices, tickets, and internal sections. If this is your first time launching the system for multiple employees, watch the video before doing a bulk user rollout.

Answers to Common Questions About CodeCanyon RISE

Can RISE Be Installed Through the WordPress Admin Panel?

No. According to the official sources, RISE is a standalone PHP application built on CodeIgniter, not a WordPress plugin. It needs to be deployed separately on a server, subdomain, or separate directory. You should not try to install that archive through the WordPress Plugins section.

Can RISE Be Used Alongside a WordPress Site?

Yes. That is a sensible setup if RISE handles projects, clients, invoices, tickets, and team collaboration while WordPress remains the public-facing site. But do not describe that arrangement as an official integration unless you are using a confirmed connector or your own custom implementation built on documented mechanisms.

Which Settings Matter Most Right After Installation?

Start by checking app settings, email settings, modules, notification settings, the cron job, roles, client portal permissions, and a basic project. If those layers are not working correctly, do not move on to payments, AI Assistant, Slack, Pusher, GitHub, or third-party plugins.

Why Are Recurring Tasks Not Being Created Automatically?

RISE documentation states that recurring tasks require a cron job. Check the command in Settings > App settings > Cron job, the PHP path, the run log in your hosting panel, and the minimum cron interval. Also confirm that the recurring tasks feature itself is enabled in task settings.

What Should I Do If the Client Cannot See Tasks in the Portal?

Check Settings > Client portal > Client permissions, confirm that the client contact has been added to the project, make sure the contact appears in the client contacts section, and verify that the required item is not hidden in the client portal left menu. Use a separate test client account for validation rather than an admin user.

Can RISE Be Extended with Plugins?

Yes. RISE has its own plugin system, install plugins page, hooks, and functions for developers. But these are not WordPress plugins. Third-party RISE extensions should be reviewed separately for ZIP structure, compatibility, support ownership, updates, database tables, and whether they can be disabled safely.

Does Every Installation Need AI Assistant?

No. AI Assistant is useful when you already have a knowledge base, recurring ticket patterns, and a person responsible for reviewing the answers. RISE documentation is transparent that quality depends on the provider, model, training data, and instructions. For critical client-facing replies, keep human review in place.

When Should I Look at Alternatives to RISE?

If you need a WordPress feature inside the site itself, look for a WordPress plugin. If you need an ERP-style setup with an open license, look at Dolibarr. If your main focus is classic CRM-driven sales, compare SuiteCRM or Perfex. If you want HR and project management in a Laravel-based stack, review Worksuite.

When CodeCanyon RISE Is the Right Choice

CodeCanyon RISE is worth using if you want to build a full operations workspace around a website or client service work: projects, tasks, Kanban, files, time tracking, clients, a portal, invoices, tickets, a knowledge base, notifications, and integrations. It is especially useful for teams that maintain websites, manage multiple clients, and want visibility from the first inquiry all the way to the completed task and the issued invoice.

The key is not to expect WordPress plugin behavior from RISE. It will not add a block to the WordPress editor and it will not appear in the Plugins list. Its strength is somewhere else: a separate work management system that can live next to WordPress and serve as both an internal and client-facing hub. If that matches your use case, then after validating the server, roles, email, cron, and client portal, you can download the CodeCanyon RISE archive and begin testing it on a site copy or separate subdomain first.

Before you roll it out to real clients, walk through the full control path: the administrator installs it and checks the server, the manager creates the client and project, the contributor completes a task, the client can see the portal, a ticket becomes a support request, the invoice displays correctly, notifications reach the right people, and backups are already in place. Only after that does RISE become more than just another installed script. It becomes a working system that helps both your team and your clients.