Evolve Your Application
What you have now is a working application. It runs in your workspace, on the data you gave it, for you alone. Four changes take it to production, where colleagues use it every day:
- Connect live data: point your application at the system that holds your records, such as Snowflake, SAP, or Salesforce, so no manual upload is needed whenever that data changes.
- Deploy the application: send it to staging for your colleagues to check, then to production for your users, because your workspace stops running when you stop working.
- Get your code into GitHub: link a repository, so colleagues can review your changes and a deployment can rebuild from a branch.
- Decide who sees which records: ask the agent for the roles your application needs, then assign real people to those roles. Until you define roles, every user sees every record.
Once people are using the application, more work arrives from three sources: requests from users, new capabilities C3 AI releases, and new data worth a model.
Connect the systems that hold your data
So far your application may hold data from a file. Each change to that data requires a new file upload.
Connect the system that holds your records instead, and the pipeline pulls new data as that system changes. Snowflake, Databricks, SAP HANA, Salesforce, ServiceNow, Oracle, SQL Server, Kafka, Amazon S3, and SharePoint are all supported, and the connector reference lists the rest.
Get the connection details from the team that runs that system, point Data Fusion at the system under Configure, then ask the agent to bring the data in.
Your records stay yours once they arrive. C3 AI does not use your data to train models.
For what each tool in Configure does, see Use Configuration Tools.
Get your work into GitHub
Connect a repository if you have not already. Without one, no colleague can review your changes, you cannot add a second workspace, and a deployment cannot rebuild from a branch.
Connect GitHub covers connecting your account and linking a repository.
Put the application where people can use it
Your application gets two running copies, and both keep running after your workspace stops. Staging is where you and your colleagues check the application. Production is the copy your users use.
Production runs all the time by default. It requires no manual start and no monitoring, and it does not stop when an administrator is unavailable. Staging hibernates at a scheduled time, and a user with access resumes it before the next use. Production also handles more people at once than staging, so a spike in usage needs no action from you.
Deploy to staging first and review the result there. Deploy the same code to production once the application performs as you expect. From then on, every change takes the same path, so your users only ever see work your team has checked.
Deciding who sees which records belongs here too, because until you define roles every user sees every record. Ask the agent for the rules you need, then assign real people to those roles in Configure.
Deploy to Staging and Production covers the deploy procedure itself, and Share with Collaborators covers adding people and sharing a preview link.
Change what the application does
All three routes write to the same code, so choose by what the change involves:
- Prompt the agent for anything that spans files. New records, new pages, new logic, and changes that touch the data and the pages together belong here. The agent writes the code and checks the result.
- Use Configure for a visual adjustment to a page that already renders correctly. Setting a value takes less time than writing a prompt to set that value.
- Use Code for a change you can describe more precisely as an edit than as a sentence. Reading what the agent wrote belongs here too.
The agent reports what it checked after each change. Read that report, then confirm the change yourself in Preview, because the next change starts from the state this change leaves.
Maintain the application once people are using it
Once people use the application every day, they ask for changes: a new page, a new metric, another kind of record. A warehouse lead asks for a supplier scorecard next to the reorder list. Each request is a prompt, and each goes to staging before production.
New data is often worth more than a pipeline change. Ask the agent for a model over the new records, or for new inputs to the models your application already runs, in the same way you ask for a page.
C3 AI also releases new capabilities in the platform and in application modules, and an application you built earlier does not receive those automatically. Ask the agent what a release offers your application, then ask for the parts you want. Upgrade Your Environment and Application covers what an upgrade involves at the platform level.
Run more than one chat
Each chat in the chat panel runs its own agent, so a long change can run in one chat while you ask a question in another.
For running more than one chat at a time, see Work in Multiple Chats.
Add a second workspace when you need one
A second workspace gives a colleague a space of their own, or gives you a place to test a large change without disturbing what already works.
Workspaces isolate data, and branches isolate code. Each workspace runs a database of its own, so records you type in one workspace do not appear in another.
For working in more than one workspace, see Use Multiple Workspaces for One App.
Change settings that apply to the whole application
The application Settings tab holds what belongs to the application rather than to one workspace. The tab covers the application name, the connected repository, the build pipelines that rebuild a deployment, and the compute behind every new workspace.
For what each setting does, see Application Settings.
Where to go next
These pages cover each way of changing the application, and the settings behind the application: